Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

rtfm

Retrieve comprehensive, on-demand documentation for any XC-MCP tool via progressive disclosure. Provides full usage details, parameters, and examples to understand each tool's purpose and operation.

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 28 consolidated tools in this MCP server (v2.0+). This implements progressive disclosure: tool descriptions in the main list include full documentation (~18.7k tokens total for optimal agent understanding), while rtfm provides additional context and examples on demand.

Version History:

  • v1.x: 51 individual tools (~3,000-7,850 tokens depending on approach)

  • v2.0+: 28 consolidated tools (~18.7k tokens) - Comprehensive docs for optimal reasoning

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-device", "idb-app", "cache", "persistence"

    • 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 consolidated simulator device tool
rtfm({ toolName: "simctl-device" })

// Get documentation for consolidated app management tool
rtfm({ toolName: "idb-app" })

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

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

Migration from v1.x to v2.0

Old individual tools are now consolidated into single tools with operation parameters:

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

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

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

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

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

  • idb-targets extended with idb-connect and idb-disconnect operations

For detailed examples and parameter specifications for each operation, use rtfm({ toolName: "simctl-device" }) etc.

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 (6)

  • simctl-list, simctl-get-details, simctl-device (consolidated: boot/shutdown/create/delete/erase/clone/rename)

  • simctl-suggest, simctl-health-check

Simctl App Management Tools (3)

  • simctl-app (consolidated: install/uninstall/launch/terminate)

  • simctl-get-app-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 (6)

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

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

  • idb-app (consolidated: install/uninstall/launch/terminate)

Cache Management Tools (2)

  • list-cached-responses

  • cache (consolidated: get-stats/get-config/set-config/clear)

Persistence Tools (1)

  • persistence (consolidated: enable/disable/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
  • list-cached-responses: View cached progressive disclosure responses

  • 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
Behavior5/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It comprehensively details behavioral traits: returns markdown documentation, handles errors with fuzzy matching and suggestions, explains case sensitivity and parameter behavior, and describes the progressive disclosure pattern. This goes well beyond what annotations would provide.

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 structured with headings, bullet points, and code blocks, but it is excessively long, containing version history and implementation details that are not essential for an agent's immediate usage. While well-organized, it would benefit from trimming to focus on actionable information for the AI agent.

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?

Given the tool's role as a documentation meta-tool, the description is extremely complete. It covers purpose, parameters, examples, error handling, migration paths, categories, implementation details, and benefits. No output schema exists, but the response format is clearly described. All necessary context for correct usage is provided.

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?

The input schema has 0% coverage for parameter descriptions. The description adds significant meaning by explaining the optional toolName and categoryName parameters, providing examples, and noting case sensitivity. It adds context on usage patterns but does not explicitly define behavior when both parameters are provided simultaneously, which would elevate it to 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?

The description clearly states the tool's purpose as providing access to comprehensive documentation for all XC-MCP tools. It explicitly distinguishes itself from sibling tools by being the meta-documentation tool, with a specific verb 'rtfm' and resource 'progressive disclosure documentation system'. It explains its role in the ecosystem, making it unmistakable what the tool does.

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?

The description provides detailed guidance on when to use rtfm: to get full documentation beyond concise descriptions, explore categories, and see examples. It includes examples of usage and mentions that it supplements tool descriptions. However, it lacks explicit 'when not to use' guidance or alternatives, though the context implies it is supplementary. Score is 4 due to clear context but absence of explicit exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/conorluddy/xc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server