Skip to main content
Glama

xcode_debug

Start debugging sessions for Xcode projects by specifying project paths and optional schemes to identify and resolve issues in iOS/macOS development.

Instructions

Start debugging session for a specific project. ⏱️ Can run indefinitely - do not timeout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xcodeprojYesAbsolute path to the .xcodeproj file (or .xcworkspace if available) - e.g., /path/to/project.xcodeproj
schemeNoScheme name (optional)
skip_buildingNoWhether to skip building

Implementation Reference

  • Core handler implementation for xcode_debug tool. Validates project path, optionally opens project, executes JXA script to invoke Xcode's workspace.debug() with optional scheme and skip_building parameters, handles build alerts, and returns result.
    public static async debug(
      projectPath: string, 
      scheme?: string, 
      skipBuilding = false, 
      openProject?: OpenProjectCallback
    ): Promise<McpResult> {
      const validationError = PathValidator.validateProjectPath(projectPath);
      if (validationError) return validationError;
    
      if (openProject) {
        await openProject(projectPath);
      }
    
      const hasParams = scheme || skipBuilding;
      let paramsObj: { scheme?: string; skipBuilding?: boolean } = {};
      if (scheme) paramsObj.scheme = scheme;
      if (skipBuilding) paramsObj.skipBuilding = skipBuilding;
      
      const script = `
        (function() {
          ${getWorkspaceByPathScript(projectPath)}
          
          ${hasParams 
            ? `const result = workspace.debug(${JSON.stringify(paramsObj)});`
            : `const result = workspace.debug();`
          }
          return \`Debug started. Result ID: \${result.id()}\`;
        })()
      `;
      
      const result = await JXAExecutor.execute(script);
      
      // Check for and handle "replace existing build" alert
      await this._handleReplaceExistingBuildAlert();
      
      return { content: [{ type: 'text', text: result }] };
    }
  • MCP CallToolRequestSchema dispatch case that validates parameters and delegates to BuildTools.debug().
    case 'xcode_debug':
      if (!args.xcodeproj) {
        throw new McpError(ErrorCode.InvalidParams, `Missing required parameter: xcodeproj`);
      }
      if (!args.scheme) {
        throw new McpError(ErrorCode.InvalidParams, `Missing required parameter: scheme`);
      }
      return await BuildTools.debug(
        args.xcodeproj as string, 
        args.scheme as string, 
        args.skip_building as boolean, 
        this.openProject.bind(this)
      );
  • Input schema definition for xcode_debug tool, including parameters xcodeproj (required unless preferred), scheme (optional), skip_building (optional). Used by MCP ListTools and CLI.
      name: 'xcode_debug',
      description: 'Start debugging session for a specific project. ⏱️ Can run indefinitely - do not timeout.',
      inputSchema: {
        type: 'object',
        properties: {
          xcodeproj: {
            type: 'string',
            description: preferredXcodeproj 
              ? `Absolute path to the .xcodeproj file (or .xcworkspace if available) - defaults to ${preferredXcodeproj}`
              : 'Absolute path to the .xcodeproj file (or .xcworkspace if available) - e.g., /path/to/project.xcodeproj',
          },
          scheme: {
            type: 'string',
            description: preferredScheme 
              ? `Scheme name (optional) - defaults to ${preferredScheme}` 
              : 'Scheme name (optional)',
          },
          skip_building: {
            type: 'boolean',
            description: 'Whether to skip building',
          },
        },
        required: preferredXcodeproj ? [] : ['xcodeproj'],
      },
    },
  • MCP ListToolsRequestSchema handler that dynamically registers xcode_debug (via getToolDefinitions) with its schema for MCP protocol discovery.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => {
      const toolOptions: {
        includeClean: boolean;
        preferredScheme?: string;
        preferredXcodeproj?: string;
      } = { includeClean: this.includeClean };
      
      if (this.preferredScheme) toolOptions.preferredScheme = this.preferredScheme;
      if (this.preferredXcodeproj) toolOptions.preferredXcodeproj = this.preferredXcodeproj;
      
      const toolDefinitions = getToolDefinitions(toolOptions);
      return {
        tools: toolDefinitions.map(tool => ({
          name: tool.name,
          description: tool.description,
          inputSchema: tool.inputSchema
        })),
      };
  • Categorizes xcode_debug as a build tool for environment validation and limitation checks (requires Xcode, permissions, etc.).
    const buildTools = ['xcode_build', 'xcode_test', 'xcode_build_and_run', 'xcode_debug', 'xcode_clean'];
    const xcodeTools = [...buildTools, 'xcode_open_project', 'xcode_get_schemes', 'xcode_set_active_scheme', 
                       'xcode_get_run_destinations', 'xcode_get_workspace_info', 'xcode_get_projects'];
    const xcresultTools = ['xcresult_browse', 'xcresult_browser_get_console', 'xcresult_summary', 'xcresult_get_screenshot', 'xcresult_get_ui_hierarchy', 'xcresult_get_ui_element', 'xcresult_list_attachments', 'xcresult_export_attachment'];
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: '⏱️ Can run indefinitely - do not timeout' warns about potential long-running sessions, which is crucial for agent planning. However, it lacks details on permissions, side effects, or response format, leaving some behavioral aspects unclear.

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 extremely concise with two sentences: one states the core purpose, and the other adds critical behavioral context. Every word earns its place, and it's front-loaded with the main action, making it efficient and easy to parse without any waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a tool that starts a debugging session—a potentially complex operation. It covers the basic purpose and a key behavioral trait (indefinite runtime), but misses details like what the tool returns, error conditions, or dependencies on other tools (e.g., needing a built project). This leaves gaps in contextual understanding.

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 the schema fully documents all parameters (xcodeproj, scheme, skip_building). The description adds no additional meaning or examples beyond what's in the schema, such as clarifying how debugging interacts with building or scheme selection. Thus, it meets the baseline but doesn't enhance parameter understanding.

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?

The description clearly states the action ('Start debugging session') and target ('for a specific project'), which is specific and actionable. It distinguishes from siblings like xcode_build, xcode_test, or xcode_stop by focusing on debugging. However, it doesn't explicitly differentiate from xcode_build_and_run or other execution-related tools, keeping it from a perfect score.

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

Usage Guidelines3/5

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

The description implies usage for debugging a project, but provides no explicit guidance on when to use this tool versus alternatives like xcode_build_and_run or xcode_test. The context of sibling tools suggests overlapping purposes (e.g., building, testing, running), yet no comparisons or exclusions are mentioned, leaving usage somewhat ambiguous.

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/lapfelix/XcodeMCP'

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