Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

xcodebuild-get-details

Retrieve specific details from cached Xcode build results, including logs, errors, warnings, summaries, commands, or metadata, using a build ID and detail type to streamline debugging and analysis.

Instructions

Get detailed information from cached build results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buildIdYesBuild ID from previous xcodebuild-build call
detailTypeYesType of details to retrieve
maxLinesNoMaximum number of lines to return for logs

Implementation Reference

  • The primary handler function xcodebuildGetDetailsTool that implements the core logic for retrieving cached build/test details, filtering logs, and returning formatted responses based on detailType.
    export async function xcodebuildGetDetailsTool(args: any) {
      const { buildId, detailType, maxLines = 100 } = args as GetDetailsArgs;
    
      try {
        if (!buildId) {
          throw new McpError(ErrorCode.InvalidParams, 'buildId is required');
        }
    
        const cached = responseCache.get(buildId);
        if (!cached) {
          throw new McpError(
            ErrorCode.InvalidParams,
            `Build ID '${buildId}' not found or expired. Use a recent build ID from xcodebuild-build.`
          );
        }
    
        let responseText: string;
    
        switch (detailType) {
          case 'full-log': {
            const fullLog =
              cached.fullOutput + (cached.stderr ? '\n--- STDERR ---\n' + cached.stderr : '');
            const lines = fullLog.split('\n');
            if (lines.length > maxLines) {
              responseText = JSON.stringify(
                {
                  buildId,
                  detailType,
                  totalLines: lines.length,
                  showing: `Last ${maxLines} lines`,
                  content: lines.slice(-maxLines).join('\n'),
                  note: `Use maxLines parameter to see more. Total: ${lines.length} lines available.`,
                },
                null,
                2
              );
            } else {
              responseText = JSON.stringify(
                {
                  buildId,
                  detailType,
                  totalLines: lines.length,
                  content: fullLog,
                },
                null,
                2
              );
            }
            break;
          }
    
          case 'errors-only': {
            const allOutput = cached.fullOutput + '\n' + cached.stderr;
            const errorLines = allOutput
              .split('\n')
              .filter(
                line =>
                  line.includes('error:') ||
                  line.includes('** BUILD FAILED **') ||
                  line.toLowerCase().includes('fatal error')
              );
            responseText = JSON.stringify(
              {
                buildId,
                detailType,
                errorCount: errorLines.length,
                errors: errorLines.slice(0, maxLines),
                truncated: errorLines.length > maxLines,
              },
              null,
              2
            );
            break;
          }
    
          case 'warnings-only': {
            const warningLines = (cached.fullOutput + '\n' + cached.stderr)
              .split('\n')
              .filter(line => line.includes('warning:'));
            responseText = JSON.stringify(
              {
                buildId,
                detailType,
                warningCount: warningLines.length,
                warnings: warningLines.slice(0, maxLines),
                truncated: warningLines.length > maxLines,
              },
              null,
              2
            );
            break;
          }
    
          case 'summary':
            responseText = JSON.stringify(
              {
                buildId,
                detailType,
                ...cached.metadata,
                command: cached.command,
                exitCode: cached.exitCode,
                timestamp: cached.timestamp,
                tool: cached.tool,
              },
              null,
              2
            );
            break;
    
          case 'command':
            responseText = JSON.stringify(
              {
                buildId,
                detailType,
                command: cached.command,
                exitCode: cached.exitCode,
                executedAt: cached.timestamp,
              },
              null,
              2
            );
            break;
    
          case 'metadata':
            responseText = JSON.stringify(
              {
                buildId,
                detailType,
                metadata: cached.metadata,
                cacheInfo: {
                  tool: cached.tool,
                  timestamp: cached.timestamp,
                  outputSize: cached.fullOutput.length,
                  stderrSize: cached.stderr.length,
                },
              },
              null,
              2
            );
            break;
    
          default:
            throw new McpError(
              ErrorCode.InvalidParams,
              `Invalid detailType: ${detailType}. Must be one of: full-log, errors-only, warnings-only, summary, command, metadata`
            );
        }
    
        return {
          content: [
            {
              type: 'text' as const,
              text: responseText,
            },
          ],
        };
      } catch (error) {
        if (error instanceof McpError) {
          throw error;
        }
        throw new McpError(
          ErrorCode.InternalError,
          `xcodebuild-get-details failed: ${error instanceof Error ? error.message : String(error)}`
        );
      }
    }
  • MCP server registration for the xcodebuild-get-details tool, including Zod inputSchema validation and wrapper that calls the handler after Xcode validation.
    server.registerTool(
      'xcodebuild-get-details',
      {
        description: getDescription(XCODEBUILD_GET_DETAILS_DOCS, XCODEBUILD_GET_DETAILS_DOCS_MINI),
        inputSchema: {
          buildId: z.string(),
          detailType: z.enum([
            'full-log',
            'errors-only',
            'warnings-only',
            'summary',
            'command',
            'metadata',
          ]),
          maxLines: z.number().default(100),
        },
        ...DEFER_LOADING_CONFIG,
      },
      async args => {
        try {
          await validateXcodeInstallation();
          return await xcodebuildGetDetailsTool(args);
        } catch (error) {
          if (error instanceof McpError) throw error;
          throw new McpError(
            ErrorCode.InternalError,
            `Tool execution failed: ${error instanceof Error ? error.message : String(error)}`
          );
        }
      }
    );
  • Zod input schema defining parameters for the tool: buildId (required), detailType (enum), maxLines (optional default 100).
    inputSchema: {
      buildId: z.string(),
      detailType: z.enum([
        'full-log',
        'errors-only',
        'warnings-only',
        'summary',
        'command',
        'metadata',
      ]),
      maxLines: z.number().default(100),
    },
  • TypeScript interface defining the expected arguments for the handler function.
    interface GetDetailsArgs {
      buildId: string;
      detailType: 'full-log' | 'errors-only' | 'warnings-only' | 'summary' | 'command' | 'metadata';
      maxLines?: number;
    }
  • Exported documentation strings used in tool description and rtfm tool.
    export const XCODEBUILD_GET_DETAILS_DOCS = `
    # xcodebuild-get-details
    
    šŸ” **Retrieve detailed build or test output from cached results** - Progressive disclosure for logs.
    
    Provides on-demand access to full build and test logs that were cached during xcodebuild-build or xcodebuild-test execution. Implements progressive disclosure pattern: initial build/test responses return concise summaries to prevent token overflow, while this tool allows drilling down into full logs, filtered errors, warnings, or metadata when needed for debugging.
    
    ## Advantages
    
    • Access full build logs without cluttering initial responses
    • Filter to just errors or warnings for faster debugging
    • Retrieve exact command executed and exit code
    • Inspect build metadata and cache information
    
    ## Parameters
    
    ### Required
    - buildId (string): Cache ID from xcodebuild-build or xcodebuild-test response
    - detailType (string): Type of details to retrieve
      - "full-log": Complete stdout and stderr output
      - "errors-only": Lines containing errors or build failures
      - "warnings-only": Lines containing warnings
      - "summary": Build metadata and configuration used
      - "command": Exact xcodebuild command executed
      - "metadata": Cache info and output sizes
    
    ### Optional
    - maxLines (number): Maximum lines to return (default: 100)
    
    ## Returns
    
    - Tool execution results with requested build or test details
    - Full logs or filtered errors/warnings with line counts
    - Build metadata and execution information
    
    ## Related Tools
    
    - xcodebuild-build: Build iOS projects (returns buildId)
    - xcodebuild-test: Run tests (returns testId)
    - simctl-get-details: Get simulator list details
    
    ## Notes
    
    - Tool is auto-registered with MCP server
    - Requires valid cache ID from recent build/test
    - Cache IDs expire after 30 minutes
    - Use for debugging build failures and test issues
    `;
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies read-only access to cached data but doesn't disclose critical traits like whether this is a safe operation, potential rate limits, authentication needs, or what happens if the buildId is invalid. The mention of 'cached' hints at data retrieval, but more context is needed for a mutation-aware agent.

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 ('Get detailed information') without unnecessary words. Every part earns its place by succinctly conveying the tool's essence, making it easy to parse quickly.

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 tool's complexity (3 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on return values, error handling, or behavioral nuances, which are crucial for an agent to use it effectively. The high schema coverage helps, but without annotations or output schema, more descriptive context is needed.

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 parameters like 'buildId', 'detailType', and 'maxLines'. The description adds no additional meaning beyond implying retrieval of 'detailed information', which aligns with the schema but doesn't compensate with extra context. With high schema coverage, a baseline score of 3 is appropriate.

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') and resource ('detailed information from cached build results'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-cached-responses' or 'simctl-get-details', which might also retrieve cached information but for different resources.

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., requiring a buildId from 'xcodebuild-build'), exclusions, or comparisons to siblings like 'xcodebuild-list' or 'list-cached-responses', leaving usage context unclear.

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

Related 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