XC-MCP: XCode CLI wrapper

Overview Schema Source Related Servers Discussions Admin

Show Crash Report

idb-crash-show

Read-onlyIdempotent

Fetch a crash report summary with a cache ID, keeping full details available on demand so large reports don't flood the context.

Instructions

idb-crash-show

Fetch one crash report, summarized, with the full report available on demand.

Overview

Crash reports are large — 10KB for a trivial one and far more with full thread backtraces — so this returns a summary plus a cache ID rather than dumping the report into context. The full text is retrievable as an MCP resource at xcmcp://response/{cacheId}.

An .ips file is TWO concatenated JSON documents: a single-line header followed by a pretty-printed body. This tool parses both and merges the useful parts.

Parameters

Required

name (string): Crash report name from idb-crash-list (e.g. ".MyApp-2026-09-12-104512.ips")

Optional

udid (string): Target identifier - auto-detects if omitted

Returns

Summary with appName, bundleId, timestamp, osVersion, exception type/signal, termination reason, and the top frames of the faulting thread — usually enough to identify the cause without reading the full report. Plus cacheId and a resource link to the complete text.

Examples

const crashes = await idbCrashListTool({ bundleId: 'com.example.MyApp' });
await idbCrashShowTool({ name: crashes.crashes[0].name });

idb-crash-list: Find crash report names
xcodebuild-get-details: The same progressive-disclosure pattern for build logs

Notes

Symbol names appear only where the binary is symbolicated; unsymbolicated frames show the image and offset instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Crash report name from idb-crash-list
`udid`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Sep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral context: it returns a summary plus cache ID instead of a huge report, explains the .ips dual-JSON format, and documents symbolication limitations. This goes well beyond what the annotations alone convey. No contradiction with 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 long but tightly organized into Overview, Parameters, Returns, Examples, Related Tools, and Notes. Each section earns its place, and the most important behavioral fact—summary plus cache ID—is front-loaded. No filler or redundant restatement of the title.

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

Completeness5/5

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

With no output schema, the description fully documents the return content: appName, bundleId, timestamp, exception type, termination reason, top frames, cacheId, and resource link. It also includes an example call pattern and a note about unsymbolicated frames, making the tool's behavior and output interpretable without needing the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, but the description compensates by explaining both parameters: name is sourced from idb-crash-list with an example, and udid auto-detects when omitted. This adds practical meaning beyond the bare schema, though it does not define udid's exact format or validation rules.

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 first line states a specific action and resource: 'Fetch one crash report, summarized, with the full report available on demand.' This clearly distinguishes idb-crash-show from idb-crash-list (finding names) and other crash-related tools. The overview reinforces the tool's unique progressive-disclosure behavior.

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 establishes a clear workflow: use idb-crash-list to find crash report names, then pass one to idb-crash-show. The example concretely demonstrates this progression and the Related Tools section names idb-crash-list. It lacks an explicit 'when not to use' statement, but the context and example make the intended usage unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server