Skip to main content
Glama

xcode_get_schemes

Retrieve available build schemes from an Xcode project file to configure and manage development workflows.

Instructions

Get list of available schemes for a specific project

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 for xcode_get_schemes: validates project path, ensures project is open, executes JXA script via JXAExecutor to retrieve all schemes and active scheme from Xcode, handles empty schemes case, returns formatted JSON list.
    public static async getSchemes(projectPath: string, openProject: OpenProjectCallback): Promise<McpResult> {
      const validationError = PathValidator.validateProjectPath(projectPath);
      if (validationError) return validationError;
    
      await openProject(projectPath);
    
      const script = `
        (function() {
          ${getWorkspaceByPathScript(projectPath)}
          
          const schemes = workspace.schemes();
          const activeScheme = workspace.activeScheme();
          
          const schemeInfo = schemes.map(scheme => ({
            name: scheme.name(),
            id: scheme.id(),
            isActive: activeScheme && scheme.id() === activeScheme.id()
          }));
          
          return JSON.stringify(schemeInfo, null, 2);
        })()
      `;
      
      const result = await JXAExecutor.execute(script);
      
      // Parse the result to check if schemes array is empty
      try {
        const schemeInfo = JSON.parse(result);
        if (Array.isArray(schemeInfo) && schemeInfo.length === 0) {
          return { content: [{ type: 'text', text: 'No schemes found in the project' }] };
        }
      } catch (error) {
        // If parsing fails, return the raw result
      }
      
      return { content: [{ type: 'text', text: result }] };
    }
  • Dispatch handler in main MCP CallToolRequest switch statement: validates xcodeproj argument and delegates to ProjectTools.getSchemes.
    case 'xcode_get_schemes':
      if (!args.xcodeproj) {
        throw new McpError(ErrorCode.InvalidParams, `Missing required parameter: xcodeproj`);
      }
      return await ProjectTools.getSchemes(args.xcodeproj as string, this.openProject.bind(this));
  • JSON Schema definition for xcode_get_schemes input parameters (xcodeproj path, optional if preferred provided). Used by getToolDefinitions for ListTools response.
    {
      name: 'xcode_get_schemes',
      description: 'Get list of available schemes for a specific project',
      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'],
      },
  • Registration via dynamic tool list: calls getToolDefinitions (which includes xcode_get_schemes) in ListToolsRequest handler to provide tool metadata to MCP clients.
    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);
Behavior2/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 states it 'gets' a list, implying a read-only operation, but doesn't clarify if this requires the project to be open, what format the list returns (e.g., array of strings), or any error conditions (e.g., invalid path). This leaves significant gaps for a tool with no annotation coverage.

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, clear sentence with zero wasted words. It front-loads the core action ('Get list') and resource ('available schemes'), making it efficient and easy to parse, which is ideal for conciseness.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'schemes' are in Xcode context, the return format, or behavioral aspects like error handling. For a tool with no structured data beyond input schema, this leaves the agent under-informed about how to interpret results or handle edge cases.

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 single parameter 'xcodeproj' fully documented in the schema as an absolute path to a .xcodeproj or .xcworkspace file. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

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 verb ('Get list') and resource ('available schemes for a specific project'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'xcode_get_projects' or 'xcode_get_workspace_info', but the specificity about 'schemes' provides some implicit distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open project), exclusions, or comparisons to siblings like 'xcode_get_projects' for broader project info, leaving the agent to infer usage context solely from the tool name and description.

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