Skip to main content
Glama

xcode_close_project

Close active Xcode projects or workspaces to free system resources and prepare for new tasks. Automatically stops any running actions first for clean project management.

Instructions

Close the currently active Xcode project or workspace (automatically stops any running actions first)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xcodeprojYesAbsolute path to the .xcodeproj file (or .xcworkspace if available) - e.g., /path/to/project.xcodeproj

Implementation Reference

  • Core handler function implementing the tool logic: validates path, executes JXA script to close the Xcode workspace/project, handles errors gracefully.
    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}` }] };
      }
    }
  • MCP server dispatch handler: handles callTool requests for 'xcode_close_project', validates parameters, calls ProjectTools.closeProject, manages current project state.
    case 'xcode_close_project':
      if (!args.xcodeproj) {
        throw new McpError(ErrorCode.InvalidParams, `Missing required parameter: xcodeproj`);
      }
      try {
        const validationError = PathValidator.validateProjectPath(args.xcodeproj as string);
        if (validationError) return validationError;
        
        const closeResult = await ProjectTools.closeProject(args.xcodeproj as string);
        this.currentProjectPath = null;
        return closeResult;
      } catch (closeError) {
        // Ensure close project never crashes the server
        Logger.error('Close project error (handled):', closeError);
        this.currentProjectPath = null;
        return { content: [{ type: 'text', text: 'Project close attempted - may have completed with dialogs' }] };
      }
  • Tool schema definition including name, description, and input schema used by the MCP server for listTools and validation.
    {
      name: 'xcode_close_project',
      description: 'Close the currently active Xcode project or workspace (automatically stops any running actions first)',
      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',
          },
        },
        required: preferredXcodeproj ? [] : ['xcodeproj'],
      },
  • Server registration of all tools including 'xcode_close_project' via getToolDefinitions for the MCP listTools endpoint.
    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
        })),
      };
    });
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 and does well by disclosing key behavioral traits: it automatically stops any running actions before closing, which is crucial for understanding side effects. However, it does not mention potential errors (e.g., if no project is open) or confirmation prompts, leaving some gaps.

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 ('Close the currently active Xcode project or workspace') and adds necessary behavioral detail ('automatically stops any running actions first') without any wasted words. Every part earns its place.

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

Completeness4/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 (a destructive operation with no annotations or output schema), the description is fairly complete: it explains what the tool does and its automatic behavior. However, it lacks details on return values or error handling, which could be useful for an agent, though not strictly required without an output schema.

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?

The input schema has 100% description coverage, clearly documenting the single required parameter. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.

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 specific action ('Close') and target resource ('currently active Xcode project or workspace'), and distinguishes it from siblings like xcode_open_project by specifying the opposite operation. It also mentions the automatic behavior of stopping running actions first, which adds precision.

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 when a project needs to be closed, but does not explicitly state when to use this tool versus alternatives like xcode_stop (which might stop actions without closing) or provide context on prerequisites. It mentions stopping actions automatically, which gives some guidance but lacks explicit when/when-not instructions.

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