Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

Read The Manual (Tool Docs)

rtfm
Read-onlyIdempotent

Access comprehensive documentation for any XC-MCP tool on demand. Look up specific tools by name or browse by category to get full parameters, examples, and related tools, enabling efficient and informed usage.

Instructions

rtfm

šŸ“– Read The Manual - Progressive disclosure documentation system for all XC-MCP tools.

Overview

The rtfm tool provides access to comprehensive documentation for any of the discrete tools in this MCP server. This implements progressive disclosure: run the server with --mini to reduce every tool description to a one-liner, then call rtfm for full parameters, examples and related tools on demand.

Version History:

  • v1.x: 51 individual tools; v1.3.2 introduced rtfm

  • v2.0-v3.x: 28-30 tools behind operation-enum routers

  • v4.x: routers dissolved; discrete tools with per-tool annotations and outputSchema

Why rtfm?

Problem Solved: Tool documentation was originally stored in .md files within the src/ directory, which wouldn't be available in the published npm package (only dist/ is included in package.json "files" field).

Solution: Documentation is now embedded as TypeScript constants in each tool file, bundled into the compiled JavaScript, and accessible via this rtfm tool. This ensures documentation is always available, whether in development or in the published npm package.

Parameters

  • toolName (optional): Name of specific tool to get documentation for

    • Examples: "xcodebuild-build", "simctl-boot", "idb-ui-tap", "cache-get-stats"

    • Case-sensitive, must match exact tool registration name

  • categoryName (optional): Browse tools in a specific category

    • Examples: "build", "simulator", "app", "idb", "cache", "system"

    • Omit both parameters to see all categories

Examples

// Get documentation for a specific tool
rtfm({ toolName: "simctl-boot" })

// Removed router names still fuzzy-match to their replacements
rtfm({ toolName: "simctl-device" })

// Browse all tools in the cache category
rtfm({ categoryName: "cache" })

// View all categories (no parameters)
rtfm({})

Migration to v4.0 (routers removed)

v2/v3 consolidated routers were dissolved back into discrete tools. Annotations and outputSchema are per-tool, so each operation is now its own tool. Drop the operation field and call the matching tool name — operation-specific parameters are unchanged:

  • simctl-device(operation) → simctl-boot, simctl-shutdown, simctl-create, simctl-delete, simctl-erase, simctl-clone, simctl-rename

  • simctl-app(operation) → simctl-install, simctl-uninstall, simctl-launch, simctl-terminate

  • idb-app(operation) → idb-install, idb-uninstall, idb-launch, idb-terminate

  • cache(operation) → cache-get-stats, cache-get-config, cache-set-config, cache-clear

  • persistence(operation) → persistence-enable, persistence-disable, persistence-status

idb-targets keeps its operation enum (list/describe/focus/connect/disconnect). Passing a removed router name to this tool returns fuzzy suggestions for its replacements.

Response Format

Success Response

Returns full markdown documentation including:

  • Tool description and purpose

  • Advantages over direct CLI usage

  • Parameter specifications with types and descriptions

  • Usage examples

  • Related tools

  • Common patterns and best practices

Tool Not Found Response

If toolName doesn't match any registered tool:

  • Error message with the attempted tool name

  • Suggestions based on partial matches (up to 5)

  • Complete list of all available tools

Example:

No documentation found for tool: "simctl-boo"

Did you mean one of these?
  - simctl-boot
  - simctl-shutdown

Available tools (28 total):
  - xcodebuild-*
  - simctl-*
  - idb-*
  - cache
  - persistence
  - rtfm

Available Tool Categories (v2.0)

Xcodebuild Tools (7)

  • xcodebuild-version, xcodebuild-list, xcodebuild-showsdks

  • xcodebuild-build, xcodebuild-clean, xcodebuild-test

  • xcodebuild-get-details

Simctl Lifecycle Tools

  • simctl-list, simctl-get-details, simctl-boot, simctl-shutdown, simctl-create, simctl-delete, simctl-erase, simctl-clone, simctl-rename

  • simctl-suggest, simctl-health-check

Simctl App Management Tools

  • simctl-install, simctl-uninstall, simctl-launch, simctl-terminate

  • simctl-get-app-container, simctl-container, simctl-openurl

Simctl I/O & Testing Tools (7)

  • simctl-io, simctl-addmedia, simctl-privacy, simctl-push

  • simctl-pbcopy, simctl-status-bar, screenshot

IDB Tools

  • idb-targets (list/describe/focus/connect/disconnect)

  • idb-ui-tap, idb-ui-input, idb-ui-gesture, idb-ui-describe, idb-ui-find-element, idb-list-apps

  • idb-install, idb-uninstall, idb-launch, idb-terminate

Cache Management Tools (4)

  • cache-get-stats, cache-get-config, cache-set-config, cache-clear

Persistence Tools (3)

  • persistence-enable, persistence-disable, persistence-status

Documentation Tool (1)

  • rtfm (this tool!)

Implementation Details

Documentation Storage

Each tool file exports a TOOL_NAME_DOCS constant containing its full documentation in markdown format:

// Example from src/tools/simctl/boot.ts
export const SIMCTL_BOOT_DOCS = `
# simctl-boot
...
`;

Central Registry

All documentation constants are imported and mapped in src/tools/docs-registry.ts:

export const TOOL_DOCS: Record<string, string> = {
  'simctl-boot': SIMCTL_BOOT_DOCS,
  'xcodebuild-build': XCODEBUILD_BUILD_DOCS,
  // ... 49 more tools
};

Progressive Disclosure Pattern

  1. Tool list shows concise descriptions (~300-400 tokens)

  2. Each description ends with: "šŸ“– Use rtfm with toolName: '{name}' for full documentation."

  3. Full documentation accessed only when explicitly requested via rtfm

  4. Prevents token overflow while maintaining comprehensive documentation access

Benefits

āœ… Self-contained: No external file dependencies āœ… NPM package ready: Documentation bundled in compiled JavaScript āœ… Token efficient: Progressive disclosure keeps default views concise āœ… Always available: Works in development and production āœ… Type-safe: TypeScript constants with proper typing āœ… Searchable: Fuzzy matching with suggestions for typos āœ… Comprehensive: Full documentation including examples and parameters

Common Use Cases

Explore available tools:

// Intentionally use invalid tool name to see full list
rtfm({ toolName: "help" })

Learn specific tool usage:

rtfm({ toolName: "simctl-boot" })

Understand tool parameters:

rtfm({ toolName: "xcodebuild-build" })

Find related tools:

// Search by category prefix
rtfm({ toolName: "simctl" })  // Shows simctl-* suggestions
  • cache-get-stats: Monitor cache performance and usage

Notes

  • Tool names are case-sensitive and must match exact registration names

  • Fuzzy matching provides suggestions for close matches

  • Documentation format is consistent markdown across all tools

  • Each tool's documentation is independently maintained in its source file

  • The TOOL_DOCS registry is automatically updated when tools are added/removed

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolNameNo
categoryNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: fuzzy matching for removed router names, case-sensitivity, the 'tool not found' response format with suggestions, and the fact that documentation is embedded as TypeScript constants bundled into the compiled JavaScript. It also explains the v4.0 migration from routers to discrete tools, which is important context for agents that might try to call removed router names.

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

Conciseness3/5

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

The description is comprehensive but very long, covering version history, implementation details, migration notes, and benefits. While all information is relevant, the version history and implementation details (TypeScript constants, central registry) are more relevant to developers than to an AI agent deciding whether to call the tool. The most actionable information (parameters, examples, response format) is present but buried under extensive context.

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?

For a documentation-lookup tool with no output schema, the description is remarkably complete. It covers parameters, examples, response formats (both success and error), fuzzy matching behavior, category listings, and common use cases. An agent has everything it needs to call this tool correctly and interpret the response.

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 0%, so the description carries the full burden of parameter documentation. It does this well: toolName and categoryName are both explained with examples, case-sensitivity is noted, and the behavior of omitting both parameters is described. The only minor gap is that it doesn't explicitly state whether toolName and categoryName can be combined or are mutually exclusive.

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 clearly identifies rtfm as a documentation lookup tool with a specific verb ('Read The Manual') and resource (tool documentation). It distinguishes itself from sibling tools by explaining it provides progressive disclosure documentation for all other tools, not performing any device/simulator operation.

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?

The description explicitly explains when to use rtfm: when you need full parameters, examples, and related tools after seeing a one-liner description. It also explains the progressive disclosure pattern and how to browse by category or tool name, with examples of both valid and intentionally-invalid calls.

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