Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

Inspect Core Data / SwiftData Models

xcode-model-inspect
Read-onlyIdempotent

Inspect Core Data and SwiftData models directly from Xcode project source files without building or launching a simulator. Extract entities, attributes, relationships, and fetch requests for analysis.

Instructions

xcode-model-inspect

Inspect Core Data .xcdatamodeld packages and SwiftData @Model classes from project source files. Pure file analysis — no simulator, no build required.

What it does

Recursively walks the project path and extracts:

Core Data (.xcdatamodeld)

  • Reads .xccurrentversion to determine the active model version

  • Parses entity XML: names, isAbstract, parentEntity, representedClass

  • Attributes: name, attributeType, optional, defaultValueString

  • Relationships: name, destinationEntity, toMany, inverseName, optional

  • Fetch requests: name, predicateString

SwiftData (@Model classes)

  • Detects @Model-decorated classes via regex

  • Extracts stored properties (var/let) excluding computed and @Relationship

  • Extracts @Relationship declarations with toMany detection ([] or Array<>)

Parameters

  • projectPath (string, optional): Root of Xcode project to inspect (default: '.')

  • coreDataOnly (boolean, optional): Skip SwiftData scanning

  • swiftDataOnly (boolean, optional): Skip Core Data scanning

  • showVersions (boolean, optional): Include all .xcdatamodel version entries with current flagged

  • raw (string, optional): Dump raw source for a named model (Swift class body or Core Data entity XML)

  • verbose (boolean, optional): Include per-entity/property breakdown in summary text

Returns

JSON response with:

  • coreData: array of parsed .xcdatamodeld packages with entities, attributes, and relationships

  • swiftData: array of @Model classes with properties and relationships

  • summary: compact human-readable summary text

  • note: present when no models are found (not an error)

structuredContent: { coreDataModels, swiftDataModels, totalEntities }

Examples

Inspect all models

await xcodeModelInspectTool({ projectPath: '/path/to/MyApp' })

Core Data only with version history

await xcodeModelInspectTool({ projectPath: '/path/to/MyApp', coreDataOnly: true, showVersions: true })

Dump raw source for a specific model

await xcodeModelInspectTool({ projectPath: '/path/to/MyApp', raw: 'Task' })

Verbose output

await xcodeModelInspectTool({ projectPath: '/path/to/MyApp', verbose: true })

Skipped Directories

node_modules, DerivedData, Pods, Carthage, .git, and any directory starting with '.'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNo
verboseNo
projectPathNo
coreDataOnlyNo
showVersionsNo
swiftDataOnlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalEntitiesYes
coreDataModelsYes
swiftDataModelsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with these. Beyond the annotations, it adds genuinely useful behavior: that scanning is recursive, that certain directories are skipped (node_modules, DerivedData, Pods, Carthage, .git, dot-directories), and that a 'note' field is returned when no models are found rather than an error. This adds context the annotations don't convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headers (What it does, Parameters, Returns, Examples, Skipped Directories) and front-loads the core purpose. It is long, but for a tool with 6 optional parameters and dual Core Data/SwiftData coverage, the detail is justified. A minor critique: the exhaustive enumeration of extraction details in the 'What it does' section and the multiple examples could be trimmed slightly without losing value, but nothing is extraneous.

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?

Despite an output schema being present, the description still explains the return format (coreData, swiftData, summary, note) and the structuredContent shape. It documents all 6 parameters, provides usage examples, and specifies skipped directories. For a complex analysis tool with dual scanning modes, this is complete — an agent has everything needed to invoke it correctly for any scenario.

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

Parameters5/5

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

Schema description coverage is 0% — the JSON schema provides no descriptions for any of the 6 parameters. The description fully compensates with a dedicated Parameters section that documents each parameter (projectPath, coreDataOnly, swiftDataOnly, showVersions, raw, verbose), including types, defaults, and specific behavior (e.g., 'raw: Dump raw source for a named model'). It also provides four worked examples showing parameter combinations in action. The description carries the entire burden here and does so thoroughly.

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 states a precise verb and resource: it 'inspects Core Data .xcdatamodeld packages and SwiftData @Model classes from project source files.' It enumerates exactly what it extracts (entities, attributes, relationships, fetch requests, @Model properties) and explicitly frames itself as pure file analysis, which clearly distinguishes it from the build (xcodebuild-*), simulator (simctl-*), and device (idb-*) siblings that operate on builds or runtimes rather than source files.

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 states 'Pure file analysis — no simulator, no build required,' which signals to an agent that this tool is appropriate when model inspection is needed without a build step. It also documents skipped directories. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., when you need runtime model state rather than source definitions), leaving some inference to the agent.

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