Skip to main content
Glama
mgcrea

@mgcrea/mcp-ios-simulator

by mgcrea

iOS Simulator: Read Logs

ios_simulator_read_logs
Read-only

Read an app's log output: stdout, stderr and every Logger/os_log message the process emits, interleaved in one file. Only available for an app started with ios_simulator_launch capture_logs: true.

Instructions

Read an app's log output: stdout, stderr and every Logger/os_log message the process emits, interleaved in one file. Only available for an app started with ios_simulator_launch capture_logs: true. Returns the newest limit lines plus a next cursor; pass it back to get only what arrived since, which is how to see what one tap logged. capturing turns false once the app's process has exited, and what it wrote stays readable. A crash's backtrace is not in here — see ios_simulator_list_crash_logs — but its fatalError message is.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMost lines to return; the newest are kept and the rest counted in `omitted`. Defaults to 200 — filter rather than raising this.
cursorNoThe `next` value from the previous read, to get only newer lines. Omit to read from the start of the capture.
deviceNoWhich simulator: its UDID or its name as shown by ios_simulator_list. Omit it when exactly one is booted — that is the normal case, and IOS_SIMULATOR_ID pins it when it is not. Unlike simctl's own `booted`, this never picks arbitrarily between two.
filterNoCase-insensitive regular expression a line must match, e.g. "error|fail" or "\[Sync\]". Applied before `limit`, so it finds matches across the whole range.
bundle_idNoWhich app's capture, e.g. "io.mgcrea.Canopy". Defaults to the most recent capture.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only assert readOnlyHint=true, but the description discloses the capture lifecycle ('capturing turns false once the app's process has exited, and what it wrote stays readable') and the crash-content boundary (backtrace excluded, fatalError included). This is substantial behavioral context beyond the safety profile.

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?

Front-loaded with the core capability, then preconditions, then return contract, then boundaries. Every sentence carries distinct information — the crash-log routing and the capture-persistence note are not padding.

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?

With no output schema, the description carries the return contract itself: newest `limit` lines plus a `next` cursor. Combined with the precondition and the crash-log boundary, an agent has everything needed to call and interpret this tool 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 the baseline is 3, but the description adds integration semantics: the cursor is described in terms of the incremental workflow, filter is noted effectively in the 'see what one tap logged' framing, and the device-omission rule is reinforced. It stops short of restating every field, which is appropriate given the schema already covers them.

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 and resource ('Read an app's log output') and enumerates exactly what is captured: stdout, stderr, and Logger/os_log messages interleaved. It also distinguishes itself from the sibling ios_simulator_list_crash_logs, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition ('Only available for an app started with ios_simulator_launch capture_logs: true'), names the crash-log tool as the alternative for backtraces, and explains the incremental-read pattern ('pass it back to get only what arrived since'). When-to-use, when-not-to-use, and the alternative are all covered.

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