Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

simctl-push

Send simulated push notifications to apps on iOS simulators with custom JSON payloads. Supports test tracking to verify delivery and validate app behavior against expected outcomes.

Instructions

simctl-push

Send simulated push notifications to apps on simulators with test context tracking.

What it does

Sends push notifications with custom JSON payloads to apps, simulating remote notifications from APNS. Supports test tracking to verify push delivery and validate app behavior.

Parameters

  • udid (string, required): Simulator UDID (from simctl-list)

  • bundleId (string, required): App bundle ID (e.g., com.example.MyApp)

  • payload (string, required): JSON payload with APS dictionary

  • testName (string, optional): Test name for tracking

  • expectedBehavior (string, optional): Expected app behavior description

Payload Format

Must be valid JSON with an "aps" dictionary:

{
  "aps": {
    "alert": "Notification text",
    "badge": 1,
    "sound": "default"
  },
  "custom": "Additional data"
}

LLM Optimization

The testName and expectedBehavior parameters enable structured test tracking. This allows AI agents to verify push notification delivery and validate that app behavior matches expectations (e.g., navigation, UI updates, data refresh).

Returns

JSON response with:

  • Push delivery status

  • Delivery information (sent timestamp)

  • Test context with expected vs actual behavior

  • Guidance for verifying notification handling

Examples

Simple alert notification

await simctlPushTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  payload: JSON.stringify({
    aps: { alert: 'Test notification' }
  })
})

Notification with badge and sound

await simctlPushTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  payload: JSON.stringify({
    aps: {
      alert: 'New message',
      badge: 5,
      sound: 'default'
    }
  })
})

Rich notification with custom data

await simctlPushTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  payload: JSON.stringify({
    aps: {
      alert: {
        title: 'New Order',
        body: 'Order #1234 has been placed'
      },
      badge: 1
    },
    orderId: '1234',
    action: 'view_order'
  })
})

Push with test context tracking

await simctlPushTool({
  udid: 'device-123',
  bundleId: 'com.example.MyApp',
  payload: JSON.stringify({
    aps: { alert: 'Product available' },
    productId: '567'
  }),
  testName: 'PushNotification_DeepLinkTest',
  expectedBehavior: 'App navigates to ProductDetail view for product 567'
})

Common Use Cases

  1. Notification delivery testing: Verify app receives and displays notifications

  2. Deep link navigation: Test notification taps navigate to correct screens

  3. Badge updates: Verify badge count is updated correctly

  4. Custom data handling: Test app processes custom payload data

  5. Background behavior: Test app behavior when notification arrives in background

Important Notes

  • App must be running: Launch app first or test background notification handling

  • Payload validation: JSON must be valid and include "aps" dictionary

  • Immediate delivery: Notification is delivered immediately (no delay)

  • No user interaction: Notification appears automatically without tapping

  • Visual verification: Use simctl-io screenshot to confirm notification display

Error Handling

  • Invalid JSON: Error if payload is not valid JSON

  • App not running: May fail if app is not running (test background handling)

  • Simulator not booted: Indicates simulator must be booted first

  • Invalid bundle ID: Validates bundle ID format (must contain '.')

Testing Workflow

  1. Launch app: simctl-launch <udid> <bundleId>

  2. Send push: simctl-push <udid> <bundleId> <payload>

  3. Take screenshot: simctl-io <udid> screenshot to verify delivery

  4. Check navigation: Verify app navigated to expected screen

  5. Validate data: Confirm app processed custom payload data

Test Context Tracking

The testContext in the response includes:

  • testName: Identifier for this push notification test

  • expectedBehavior: What should happen when notification is received

  • actualBehavior: What actually happened (delivery success/failure)

  • passed: Whether test passed

This enables agents to track push notification tests and verify expected behavior.

Advanced Testing

  • Multiple notifications: Send sequential pushes to test badge accumulation

  • Different payload types: Test alert, sound-only, silent notifications

  • Content extensions: Test notification service extensions with custom content

  • Action buttons: Test notification actions and user responses

  • Notification grouping: Test thread-id for notification grouping

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidYes
bundleIdYes
payloadYes
testNameNo
expectedBehaviorNo
Behavior5/5

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

No annotations are provided, so the description fully bears the burden of transparency. It discloses key behaviors: app must be running, notification delivered immediately, no user interaction needed, payload must be valid JSON with 'aps' dictionary. It also details error conditions (invalid JSON, app not running, etc.) and mentions test context tracking.

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 well-structured with clear sections and examples, but it is quite lengthy. Some sections like 'LLM Optimization' and repeated 'Test Context Tracking' could be condensed. The front-loading of purpose is good, but overall wordiness reduces conciseness.

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 having no output schema, the description fully covers the return value (JSON with delivery status, test context, and guidance). It also explains error handling, common use cases, and advanced testing strategies. For a tool with 5 parameters and significant complexity, the description is extremely complete.

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?

The input schema has 0% description coverage, but the description thoroughly explains all five parameters: udid (from simctl-list), bundleId (app identifier), payload (JSON with aps dict), testName (for test tracking), expectedBehavior (expected app behavior). It provides multiple examples and payload format details, adding significant value beyond the schema.

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 clearly states it sends simulated push notifications to apps on simulators. It distinguishes itself from sibling tools like simctl-openurl (URL opening) and simctl-launch (app launch) by focusing on push notification simulation with test tracking. The verb-resource combination is precise.

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 provides comprehensive guidance on when to use the tool, including a testing workflow with sequential steps (launch app, send push, screenshot). It also lists common use cases (delivery testing, deep link navigation, etc.) and error handling scenarios. However, it does not explicitly state when not to use it or mention alternative tools.

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

Install Server

Other Tools

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/conorluddy/xc-mcp'

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