Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy

Send Push Notification

simctl-push

Send simulated push notifications to iOS simulator apps with custom JSON payloads and test context tracking to verify delivery and app behavior.

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
payloadYes
bundleIdYes
testNameNo
expectedBehaviorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With only sparse annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description carries the full burden and delivers rich behavioral detail: immediate delivery with no delay, no user interaction required, app-must-be-running prerequisite, payload validation requirements, specific error conditions (invalid JSON, un-booted simulator, invalid bundle ID format), and the testContext result with a passed flag. Nothing contradicts 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.

Conciseness3/5

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

The description is well-organized with clear headers and front-loading, but it is substantially bloated. 'LLM Optimization,' 'Returns,' and 'Test Context Tracking' all repeat the same testContext field information, and 'Advanced Testing' drifts into general testing techniques (content extensions, action buttons, grouping) rather than tool usage. Several examples could be condensed without losing information.

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 a bare schema (no property descriptions), minimal annotations, and no output schema, this description covers everything an agent needs: input parameters, payload JSON structure, multi-format examples, error behavior, return contract, prerequisites, and a surrounding workflow. An agent could call this tool correctly with only this description.

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%, so the description must fully compensate — and it does. A dedicated Parameters section explains all 5 parameters, the Payload Format section documents the required 'aps' dictionary with a JSON example, and four worked examples show real usage including rich alert objects, badge/sound, custom data, and test-tracking parameters.

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 line states a specific verb and resource: 'Send simulated push notifications to apps on simulators with test context tracking.' The 'simplified vs. simulated' distinction, the test-context-tracking differentiator, and the payload/aps focus clearly separate it from siblings like simctl-launch, simctl-openurl, and simctl-io.

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 'Common Use Cases' section enumerates five concrete scenarios, and the 'Testing Workflow' section explicitly sequences this tool after simctl-launch and before simctl-io screenshot verification. It also notes the prerequisite that the app must be running. However, it never explicitly names alternatives to avoid or states when not to use this tool (e.g., versus simctl-openurl for direct deep-link testing), so it stops short of a 5.

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