Skip to main content
Glama
HalidSaglam

saglitzdesign-mcp

by HalidSaglam

Audit Apple Ui

audit_apple_ui
Read-onlyIdempotent

Audit an iOS or macOS app's UI against Apple's documentation by analyzing Xcode project configuration and Swift source. Flags deprecated APIs, missing sandbox, and configuration issues with fixes.

Instructions

Audit an iOS or macOS app's UI against Apple's own documentation: point it at the project directory and it reads the four surfaces an Xcode project declares configuration on — the information property list, INFOPLIST_KEY_* build settings in project.pbxproj, the entitlements plist, and each colorset's Contents.json — infers whether the project targets iOS or macOS from those plus the Swift imports, and runs eight rules. Configuration: a custom colorset with no luminosity: dark appearance, the deprecated UIRequiresFullScreen key (either spelling), a microphone entitlement declared under one capability and not its twin, and — on macOS only — no App Sandbox entitlement, reported as a fact about the Mac App Store channel rather than as a defect. Swift: NavigationView, .font(.system(size:)) on iOS only, a colour written as numbers, and a Button whose whole label is one SF Symbol. Every platform-scoped rule stays silent when the platform signals do not settle the question, and the report says which platform was inferred and from what, so a silence can be read as the gate rather than as a result. It reads source and does not measure anything: it builds nothing, runs no simulator, takes no screenshot, and no finding is or can be a rendered-output, contrast, notarization or App Review result. Returns markdown plus structured output: findings (rule, severity, message, fix, doc, file, line — configuration findings carry no line, since a missing key has no position), a severity summary, a scan block saying how much was actually read, and a long machine-readable notVisible list of what it structurally could not check, every entry of it derived from a run. Directory only — there is no snippet mode, because configuration is the backbone of this audit and a snippet carries none of it. A missing path, a path that is a file, or a code argument is returned as an error result, not as an empty audit. Pair with get_design_doc("apple-hig-liquid-glass"), get_design_doc("apple-accessibility") and get_design_doc("apple-shipping-readiness") for the guidance behind the rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoNot supported by this tool, and rejected with an explanation if passed. There is no snippet mode: the platform verdict and half the rules are read from the information property list, the entitlements plist, `project.pbxproj` and the asset catalog, and a pasted snippet carries none of them. Pass `path` instead.
pathNoThe Xcode project directory to audit — the folder holding your `.xcodeproj`, `Info.plist`, `Assets.xcassets` and Swift sources. Required. Absolute paths are strongly preferred: a relative path is resolved against the server's working directory, which is usually not your project folder.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scanYesWhat the scan reached. Read it before trusting any absence claim: a capped scan looked at part of the project, and the platform-scoped rules are gated on configuration this scan may never have opened.
summaryYesCounts by severity. Always agrees with `findings` — it is derived from the same list.
findingsYesEvery finding, in the order the markdown report lists them.
notVisibleYesWhat this audit structurally could not check, one limitation per entry. Read it as a peer of `findings`: silence on a subject named here is this tool's reach, not a clean result. Nothing any of these tools reports is measured.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.28.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral detail: it builds nothing, runs no simulator, takes no screenshot, reports platform inference, and returns a notVisible list of unchecked items. No contradiction exists between description and annotations.

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

Conciseness3/5

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

The description is front-loaded with purpose and information-dense, but it is a lengthy block with redundancy ('no snippet mode' appears multiple times) and a long enumeration of rules and output fields. It earns its place for a complex tool, but could be tighter and better structured.

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?

The description covers purpose, input requirements, surfaces read, rule categories, platform inference, output structure, error handling, and complementary tools. An output schema exists, but the description still explains what the findings contain, making the tool well-specified for an agent to call correctly.

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 description coverage is 100%, so baseline is 3. The description adds meaning by clarifying that a path must be a directory, that missing/file paths return error results rather than empty audits, and why code is rejected. This goes slightly beyond the schema's parameter descriptions.

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 opening sentence states a specific verb and resource: 'Audit an iOS or macOS app's UI against Apple's own documentation.' It further specifies the project surfaces read and lists the eight rules, making the tool unmistakably distinct from siblings like audit_android_ui, audit_accessibility, and generic design audits.

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 gives clear context: point it at the project directory, directory only, no snippet mode, and code/missing path/file are errors. It also suggests pairing with get_design_doc calls. However, it does not explicitly name sibling alternatives (e.g., 'use audit_android_ui for Android projects') to provide when-not-to-use guidance against specific alternatives.

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

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/HalidSaglam/saglitzdesign-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server