Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Accessibility (WCAG) Audit

accessibility-audit
Read-onlyIdempotent

Audits the live iOS simulator accessibility tree against WCAG rules, returning a severity summary and prioritized fixable issues.

Instructions

accessibility-audit

WCAG-aligned accessibility audit of the live iOS simulator accessibility tree.

Overview

Fetches the full accessibility tree via idb ui describe-all, flattens it, and evaluates every element against a tiered rule set (critical → warning → info). Returns a severity summary and either the full issue list (verbose mode) or the top issues grouped by rule.

Distinct from accessibility-quality-check, which only scores tree richness. This tool diagnoses what is broken and how to fix it.

Parameters

Optional

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

  • verbose (boolean): Return all issues instead of grouped top-10 (default: false)

Rules

Critical — blocks assistive technology users

Rule

Condition

Fix

missing_label

Button or Link with no AXLabel

Add accessibilityLabel

empty_button

Button with no AXLabel AND no AXValue

Set button title or accessibilityLabel

image_no_alt

Image with no AXLabel

Add accessibilityLabel with description

Warning — degrades UX

Rule

Condition

Fix

missing_hint

Slider or TextField with no help text

Add accessibilityHint

missing_traits

Element has type but no traits

Set appropriate accessibilityTraits

small_touch_target

Tappable frame < 44×44pt

Increase tappable area to at least 44×44pt

Info — best-practice suggestions

Rule

Condition

Fix

no_identifier

Element missing AXUniqueId

Add accessibilityIdentifier for testing

deep_nesting

Element depth > 5

Simplify view hierarchy

Returns

  • summary: { total, critical, warning, info }

  • issues (verbose mode): Full issue list

  • topIssues (default): Issues grouped by rule, sorted by severity then count, capped at 10

Structured Content

{ "total": 3, "critical": 1, "warning": 1, "info": 1 }

Examples

// Quick audit — top issues only
const result = await accessibilityAuditTool({});

// Full details for CI reporting
const result = await accessibilityAuditTool({ verbose: true });

Related Tools

  • accessibility-quality-check: Richness score — use before deciding accessibility vs screenshot

  • idb-ui-describe: Full accessibility tree for manual inspection

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidNo
verboseNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
infoYes
totalYes
warningYes
criticalYes

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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by explaining the underlying implementation (fetches via `idb ui describe-all`) and the non-destructive analysis pipeline, which aligns with the annotations. There is no contradiction, and the description enriches the behavioral context beyond the 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 meticulously structured with headers, tables for rules, JSON examples, and code snippets. It front-loads the core purpose and parameter details, then provides reference tables. Every section earns its place, making it easy to scan and parse without redundancy.

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?

Given the output schema is present (illustrated via JSON example), the description still fully covers the return structure (summary, issues, topIssues), rules, parameter options, and related tools. All necessary information for correct invocation and interpretation is provided, and the examples clarify both default and verbose usage.

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 0%, so the description carries full parameter documentation. It clearly explains 'udid' (auto-detects if omitted) and 'verbose' (returns all issues vs grouped top-10) with defaults, adding meaning beyond the bare types. While concise, it fully covers what the agent needs to know.

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?

States a specific verb ('audits') and resource ('live iOS simulator accessibility tree'), and explicitly distinguishes from 'accessibility-quality-check' by noting it diagnoses what is broken and how to fix it. The overview, rule tables, and return types make the purpose unmistakable.

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?

Provides clear usage context by contrasting with 'accessibility-quality-check' (richness score) and listing related tools with brief guidance. It implies when to use this tool (when you need to diagnose accessibility issues) but does not explicitly state when not to use it or alternative conditions, so it falls short of a perfect 5.

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

Deploy Server

Other Tools