Skip to main content
Glama

xcode_refresh_project

Refresh Xcode projects to detect external file changes by closing and reopening the project file.

Instructions

Refresh/reload an Xcode project by closing and reopening it to pick up external changes like modified .xctestplan files

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xcodeprojYesAbsolute path to the .xcodeproj file (or .xcworkspace if available) to refresh

Implementation Reference

  • Main handler logic for the xcode_refresh_project tool. Validates input, closes the project, reopens it to refresh, and returns status.
    case 'xcode_refresh_project':
      if (!args.xcodeproj) {
        throw new McpError(ErrorCode.InvalidParams, `Missing required parameter: xcodeproj`);
      }
      // Close and reopen the project to refresh it
      await ProjectTools.closeProject(args.xcodeproj as string);
      const refreshResult = await ProjectTools.openProjectAndWaitForLoad(args.xcodeproj as string);
      return {
        content: [{
          type: 'text',
          text: `Project refreshed: ${refreshResult.content?.[0]?.type === 'text' ? refreshResult.content[0].text : 'Completed'}`
        }]
      };
  • Tool schema definition including input validation schema, used for tool registration and listTools response.
      name: 'xcode_refresh_project',
      description: 'Refresh/reload an Xcode project by closing and reopening it to pick up external changes like modified .xctestplan files',
      inputSchema: {
        type: 'object',
        properties: {
          xcodeproj: {
            type: 'string',
            description: 'Absolute path to the .xcodeproj file (or .xcworkspace if available) to refresh',
          },
        },
        required: ['xcodeproj'],
      },
    },
  • Helper function to close the Xcode project using JXA scripting, called by the refresh handler.
    public static async closeProject(projectPath: string): Promise<McpResult> {
      // Simplified close project to prevent crashes - just close without complex error handling
      const closeScript = `
        (function() {
          try {
            ${getWorkspaceByPathScript(projectPath)}
            if (!workspace) {
              return 'No workspace to close (already closed)';
            }
            
            // Simple close (no options) to align with test mocks and avoid dialogs
            workspace.close();
            return 'Project close initiated';
          } catch (error) {
            return 'Close completed (may have had dialogs): ' + error.message;
          }
        })()
      `;
      
      try {
        const result = await JXAExecutor.execute(closeScript);
        return { content: [{ type: 'text', text: result }] };
      } catch (error) {
        // Even if JXA fails, consider it successful to prevent crashes
        const errorMessage = error instanceof Error ? error.message : String(error);
        return { content: [{ type: 'text', text: `Project close completed with issues: ${errorMessage}` }] };
      }
    }
  • Helper function to open the Xcode project and wait for it to fully load, called by the refresh handler.
    public static async openProjectAndWaitForLoad(projectPath: string): Promise<McpResult> {
      // First check if project is already open and loaded
      try {
        const checkScript = `
          (function() {
            try {
              ${getWorkspaceByPathScript(projectPath)}
              if (!workspace) {
                return JSON.stringify({ isOpen: false });
              }
              
              // Check if it's the right project
              const workspacePath = workspace.path();
              if (workspacePath === ${JSON.stringify(projectPath)}) {
                // Try to access schemes to see if it's fully loaded
                const schemes = workspace.schemes();
                return JSON.stringify({ isOpen: true, isLoaded: schemes.length > 0 });
              }
              
              return JSON.stringify({ isOpen: false, differentProject: workspacePath });
            } catch (error) {
              return JSON.stringify({ isOpen: false, error: error.message });
            }
          })()
        `;
        
        const result = await JXAExecutor.execute(checkScript);
        const status = JSON.parse(result);
        
        if (status.isOpen && status.isLoaded) {
          return { content: [{ type: 'text', text: 'Project is already open and loaded' }] };
        }
      } catch (error) {
        // Continue with opening the project
      }
    
      // Open the project
      const openResult = await this.openProject(projectPath);
      if (openResult.content?.[0]?.type === 'text' && openResult.content[0].text.includes('Error')) {
        return openResult;
      }
    
      // Wait for the project to load
      const waitResult = await this.waitForProjectToLoad(projectPath);
      if (waitResult) {
        return waitResult;
      }
    
      return { content: [{ type: 'text', text: 'Project opened and loaded successfully' }] };
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the behavioral trait of closing and reopening the project, which implies a disruptive action (temporary unavailability). However, it lacks details on permissions needed, error handling, or whether this affects other open projects. The description does not contradict any annotations.

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 a single, efficient sentence that front-loads the core action ('Refresh/reload an Xcode project') and follows with necessary context. Every word earns its place, with no redundancy or unnecessary elaboration.

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 the tool's moderate complexity (disruptive refresh operation), no annotations, and no output schema, the description is adequate but has gaps. It explains the what and why but lacks details on outcomes (e.g., success indicators, error cases) or side effects, which would be helpful for an agent to use it correctly.

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%, with the parameter 'xcodeproj' well-documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

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 verb ('refresh/reload') and resource ('Xcode project'), and specifies the mechanism ('by closing and reopening it') and purpose ('to pick up external changes like modified .xctestplan files'). It distinguishes from siblings like 'xcode_close_project' (which only closes) and 'xcode_open_project' (which only opens).

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 clear context for when to use this tool ('to pick up external changes like modified .xctestplan files'), which implies it should be used after external modifications. However, it does not explicitly state when not to use it or name alternatives among siblings, such as whether to use 'xcode_close_project' + 'xcode_open_project' separately instead.

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