Xcode MCP Diagnostics

Xcode MCP Diagnostics

Overview

Use Xcode MCP diagnostics when the answer must reflect what Xcode currently shows, not just local filesystem analysis.

Tool Availability

Before calling MCP tools, confirm the mcp__xcode namespace is available. If it is not available, use tool_search to expose Xcode MCP tools; if the tools still are not available, tell the user Xcode MCP is not connected and stop rather than fabricating Xcode diagnostics.

Workflow

1. Discover the active Xcode tabs with mcp__xcode.XcodeListWindows.
2. Select the tabIdentifier for the relevant workspace/project.
3. For build outcome or build task errors, call mcp__xcode.GetBuildLog.
4. For current Issue Navigator contents, call mcp__xcode.XcodeListNavigatorIssues.
5. For diagnostics in a specific source file, call mcp__xcode.XcodeRefreshCodeIssuesInFile with the file path as Xcode knows it.

Filters

• Use severity: "error" first for failures.
• Use severity: "warning" when the user asks for warnings or when an error-only query is empty but the build did not behave as expected.
• Use severity: "remark" only when the user asks for full detail or when narrowing a non-error build issue.
• Use glob for file/path filtering and pattern for message regex filtering.

Reporting

• Lead with the concrete errors or warnings, grouped by file when useful.
• Include buildResult, buildIsRunning, fullLogPath, and totalFound when GetBuildLog returns them.
• If Issue Navigator and build log disagree, say so explicitly and explain which surface each result came from.
• If MCP calls time out, state that Xcode MCP did not return diagnostics reliably; do not invent build status.

Constraints

• Prefer Xcode MCP diagnostic surfaces over shell parsing when the user asks what Xcode shows.
• Keep output concise; summarize repetitive diagnostics and include the most actionable file/message pairs.
• Do not claim a build was successful solely because there are no Issue Navigator errors; confirm with GetBuildLog when possible.