rn-device-mcp

Overview Schema Source Related Servers Discussions Admin

Simulator logs

ios_logs

Read-only

Fetch recent iOS Simulator unified log lines and filter them by app process, message substring, or time window to debug React Native console output and runtime errors.

Instructions

Recent unified-log lines from the simulator. Filter by process (the app's product name, e.g. 'MyApp') and/or a substring. JS console output from RN shows up under the app process.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ios_logs"
  }
}

Input Schema

Name	Required	Description
`device`	No	Simulator udid or name. Default "booted" (the running simulator).
`process`	No	Process name to filter on, usually the app name
`contains`	No	Case-insensitive substring filter on the message
`maxLines`	No	Default 200 (the last ones)
`lastMinutes`	No	Window, default 2

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral insight that RN JS console output surfaces under the app process and that results are 'recent' (schema supplies the defaults), but it says nothing about the shape of a returned log line, truncation behavior, or what happens if no simulator is booted.

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?

Two short sentences, front-loaded with the resource and scope, then the filter/usage note. No padding, no repetition of schema defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All five parameters are optional and fully documented in the schema, and there is no output schema, so the description needn't enumerate return values. It covers purpose, filtering, and the RN-specific gotcha; only the returned line format and failure modes remain unstated, which is a minor gap for a simple read tool.

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 100% schema description coverage the baseline is 3, and the description earns above baseline by clarifying that 'process' means the app's product name (e.g. 'MyApp') and by tying the log source to where JS console output appears — meaning that the schema's terse 'usually the app name' does not convey as directly.

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 resource and scope: recent unified-log lines from the simulator, with named filter dimensions. An agent can immediately tell it apart from the Android counterpart (android_logcat) and from other iOS sibling tools.

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?

Explains how to use the filters (process and/or substring) and adds a targeted tip that React Native JS console output appears under the app process — genuinely useful when deciding which filter to pass. It stops short of explicit when-not-to-use guidance or naming the sibling alternative, but the context is clear.

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