Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Simulate Memory Warning

idb-simulate-memory-warning
Idempotent

Trigger a memory warning in an iOS simulator to test low-memory handling paths like didReceiveMemoryWarning and NSCache purging.

Instructions

idb-simulate-memory-warning

Deliver a memory warning to a simulator, to exercise low-memory code paths.

Overview

iOS reclaims memory aggressively, and the paths that respond to it — didReceiveMemoryWarning, SwiftUI cache eviction, NSCache purging — are among the least exercised in a typical test run. Bugs there surface as blank views or lost state on a real device under pressure, long after release.

This delivers the warning on demand, so those paths can be tested deliberately.

Parameters

Optional

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

  • scenario (string): Test scenario name, recorded in the audit entry

  • step (number): Step number within the scenario

Returns

Confirmation with an audit entry (timestamp, action, scenario, step) for test-run reconstruction.

Examples

// Check the app survives memory pressure mid-flow
await idbSimulateMemoryWarningTool({ scenario: 'Checkout under pressure', step: 3 });
await accessibilityQualityCheckTool({});  // did the UI survive?

Related Tools

  • idb-crash-list: Check whether the warning actually killed the app

  • accessibility-quality-check: Cheap check that the UI is still intact afterwards

  • simctl-stream-logs: Watch for memory-related log output

Notes

  • The warning is advisory: iOS may or may not terminate the app depending on its footprint.

  • Follow with idb-crash-list to distinguish "handled it" from "was jettisoned".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepNoStep number within the scenario
udidNo
scenarioNoTest scenario name for the audit entry

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as non-read-only, non-destructive, and idempotent. The description adds important behavioral context beyond those hints: the warning is advisory, iOS may or may not terminate the app depending on footprint, and the tool records an audit entry. This effectively sets expectations about nondeterministic outcomes and side effects without contradicting any annotation.

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 well-structured with a one-line summary up front, followed by Overview, Parameters, Returns, Examples, Related Tools, and Notes. Each section earns its place: the advisory note and related-tool routing are genuinely useful, and the example shows a realistic invocation with a follow-up check.

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?

For a tool with no output schema, the Returns section clearly describes the confirmation and audit entry structure (timestamp, action, scenario, step). The examples, related tools, and notes cover what an agent needs to invoke it correctly and interpret the result. No critical operational context is missing.

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?

With 67% schema coverage, the schema documents two of three parameters. The description compensates by explaining that udid auto-detects if omitted, that scenario is recorded in the audit entry, and that step is the step number within the scenario. This adds semantic value, especially for udid, which has no schema description.

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 opens with a specific verb and resource: 'Deliver a memory warning to a simulator, to exercise low-memory code paths.' It explains the precise iOS code paths affected (didReceiveMemoryWarning, SwiftUI cache eviction, NSCache purging), making the tool's purpose unambiguous and distinct from sibling tools like idb-crash-list.

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 overview identifies when to use the tool: to deliberately exercise low-memory code paths that are rarely tested. The Related Tools section gives clear follow-up actions: use idb-crash-list to check if the app was killed, accessibility-quality-check to verify UI survival, and simctl-stream-logs to watch memory logs. It does not state explicit 'when not to use' exclusions, but the guidance is clear enough.

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