Provides access to macOS and iOS system logs, crash reports, and device logs for debugging and monitoring.
Enables streaming and searching logs from connected iOS devices and simulators, including filtering by process and severity.
Allows retrieval and streaming of macOS system logs, with filtering by process, subsystem, and log level.
Facilitates log access from iOS Simulators managed by Xcode, including listing simulators and streaming live logs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@console-mcp get recent logs for com.apple.network"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for streaming and searching macOS Console.app and iOS device logs directly from Claude, GitHub Copilot, or any MCP-compatible AI assistant.
Stream real-time logs, search crash reports, filter by severity, and debug iOS simulators and physical devices — all through natural language.
List Devices - Show connected iOS devices
List Simulators - Show available iOS Simulators
Get Logs - Fetch recent logs filtered by process or subsystem
Get Device Logs - Fetch logs from connected iOS devices
Get Simulator Logs - Fetch logs from iOS Simulators
Get Logs by Level - Filter logs by severity (fault, error, warning, info, debug)
Stream Logs - Capture live logs for a specified duration
Search Logs - Search through historical logs (supports regex)
Get Crash Logs - List and read crash reports
Watch for Pattern - Stream until a pattern matches
Export Logs - Save logs to file for sharing
VPN Logs - Quick shortcut to get WorxVPN-specific logs
Related MCP server: mcp-server-logs-sieve
git clone https://github.com/rohithgoud30/console-mcp.git
cd console-mcp
npm install
npm run buildInstall libimobiledevice for direct iOS device log streaming:
brew install libimobiledeviceAdd to your .vscode/mcp.json:
{
"servers": {
"console": {
"command": "node",
"args": ["/path/to/console-mcp/dist/index.js"]
}
}
}list_devicesList connected iOS devices with their UDIDs.
list_simulatorsList available iOS Simulators.
Parameter | Type | Description |
| boolean | Only show running simulators (default: false) |
| string | Filter by runtime (e.g., 'iOS 17') |
get_logsGet recent logs from macOS.
Parameter | Type | Description |
| string | Filter by process name (e.g., 'Safari') |
| string | Filter by subsystem (e.g., 'com.apple.network') |
| number | Minutes of logs to fetch (default: 5) |
| number | Max lines to return (default: 200) |
get_logs_by_levelGet logs filtered by severity level.
Parameter | Type | Description |
| string | Log level: fault, error, warning, info, debug (required) |
| string | Filter by process name |
| number | Minutes of logs to fetch (default: 5) |
| number | Max lines to return (default: 200) |
get_device_logsGet logs from a connected iOS device. Requires libimobiledevice.
Parameter | Type | Description |
| string | Device name or UDID (required) |
| string | Filter by process name |
| number | Minutes of logs to capture (default: 5, max: 10) |
| number | Max lines to return (default: 200) |
get_simulator_logsGet logs from an iOS Simulator. Simulator must be booted.
Parameter | Type | Description |
| string | Simulator name or UDID (required) |
| string | Filter by process name |
| number | Minutes of logs to fetch (default: 5) |
| number | Max lines to return (default: 200) |
stream_logsStream live logs for a duration.
Parameter | Type | Description |
| string | Filter by process name |
| number | How long to stream (default: 10, max: 30) |
stream_simulator_logsStream live logs from an iOS Simulator.
Parameter | Type | Description |
| string | Simulator name or UDID (required) |
| string | Filter by process name |
| number | How long to stream (default: 10, max: 30) |
search_logsSearch through recent logs with text or regex.
Parameter | Type | Description |
| string | Text or regex pattern to search for (required) |
| boolean | Treat query as regex (default: false) |
| number | Minutes to search (default: 30) |
| number | Max matching lines (default: 100) |
get_crash_logsList recent crash reports from DiagnosticReports.
Parameter | Type | Description |
| string | Filter by process/app name |
| number | Days to search back (default: 7) |
| number | Max reports to list (default: 10) |
read_crash_reportRead the full content of a specific crash report.
Parameter | Type | Description |
| string | Crash report filename (required) |
watch_for_patternStream logs until a pattern matches. Great for test automation.
Parameter | Type | Description |
| string | Text or regex to watch for (required) |
| boolean | Treat pattern as regex (default: false) |
| string | Filter by process name |
| number | Max wait time (default: 30, max: 60) |
export_logsExport logs to a file on the Desktop.
Parameter | Type | Description |
| string | Log content to export (required) |
| string | Optional filename |
| string | Export format: txt or json (default: txt) |
get_vpn_logsShortcut to get WorxVPN extension logs.
Parameter | Type | Description |
| number | Minutes of logs (default: 5) |
| number | Max lines (default: 300) |
// In Copilot chat:
"List my iOS simulators"
"Get logs from iPhone 15 Pro simulator"
"Show device logs from my iPhone"
"Get the last 5 minutes of Safari logs"
"Show me all error logs from the last 10 minutes"
"Search logs for 'authentication' using regex"
"Get crash logs for MyApp"
"Read the crash report MyApp-2024-12-27.crash"
"Watch for 'connection established' while I connect"
"Export these logs to a file"
"Stream logs for 15 seconds while I reproduce the bug"
"Show me WorxVPN logs"macOS 13+ (Ventura or later)
Node.js 18+
Xcode (for simulators and xcrun tools)
libimobiledevice (optional, for iOS device logs)
macOS log command is used for local logs
xcrun simctl is used for simulator logs
idevicesyslog from libimobiledevice is used for iOS device logs
iOS device must be paired and trusted for log access
Crash reports are found in ~/Library/Logs/DiagnosticReports
Exported logs are saved to ~/Desktop/ConsoleMCP-Exports/
Originally created by devstroop. This fork includes custom modifications and enhancements.
MIT
Export logs to a file on the Desktop for sharing
| Name | Required | Description | Default |
|---|---|---|---|
| logs | Yes | The log content to export (from a previous get_logs call) | |
| format | No | Export format (default: txt) | |
| filename | No | Optional filename (auto-generated if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action and the dependency on prior get_logs calls, but does not disclose file overwrite behavior, permissions needed, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, and front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate given the parameter count and schema coverage, but could include more about file destination behavior (e.g., overwrite policy) or format-specific details. The tool's role is clear among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context for the logs parameter (dependency on previous get_logs call) beyond the schema description. Format and filename are well-covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (export), resource (logs), and destination (Desktop file for sharing), which distinguishes it from siblings like get_logs or stream_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a get_logs call via the logs parameter description, but lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent crash reports from DiagnosticReports
| Name | Required | Description | Default |
|---|---|---|---|
| process | No | Filter by process/app name | |
| lastDays | No | How many days back to search (default: 7) | |
| maxReports | No | Maximum reports to list (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does not state whether the operation is read-only, requires permissions, or what the output contains (e.g., file paths vs. content). Only 'recent' and source are hinted, but default limits are in schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no wasted words. It could be slightly more detailed without harming conciseness, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 13 sibling log tools and no output schema, the description is too minimal. It does not clarify the return format, filtering behavior, or distinct use cases, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the three parameters (process, lastDays, maxReports). The tool description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('recent crash reports') and identifies the source ('DiagnosticReports'), clearly distinguishing it from sibling tools like get_logs (general logs) or read_crash_report (reading a specific report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. the numerous sibling log tools (e.g., get_logs, get_device_logs, read_crash_report). There are no conditions, exclusions, or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from a connected iOS device. Requires libimobiledevice (brew install libimobiledevice)
| Name | Required | Description | Default |
|---|---|---|---|
| device | Yes | Device name or UDID (use list_devices to find) | |
| process | No | Filter by process/app name | |
| maxLines | No | Maximum log lines (default: 200) | |
| lastMinutes | No | How many minutes of logs to capture (default: 5, max: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only mentions a software dependency, not side effects, limitations, or whether the operation is read-only. Missing key behavioral traits like 'requires connected device'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no waste. Front-loaded with the action and immediately adds a critical prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output description, no mention of execution environment (e.g., device must be connected wirelessly or via USB), and no guidance on default behavior. Incomplete for a moderate-complexity tool with 4 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds no extra meaning to parameters. Baseline 3 is appropriate since the schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and resource: 'Get logs from a connected iOS device'. Distinguishes from simulator logs but doesn't explicitly differentiate from similar sibling tools like get_logs or stream_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a prerequisite (libimobiledevice installation) but no guidance on when to use this tool over alternatives (e.g., vs get_simulator_logs or stream_logs). Lacks context about device connection requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent logs from macOS system. Use for debugging macOS apps.
| Name | Required | Description | Default |
|---|---|---|---|
| process | No | Filter by process name (e.g., 'WorxVPNExtension', 'Safari') | |
| maxLines | No | Maximum number of log lines to return (default: 200) | |
| subsystem | No | Filter by subsystem (e.g., 'com.worxvpn.ios') | |
| lastMinutes | No | How many minutes of logs to fetch (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It states 'get recent logs' implying read-only but does not disclose any side effects, authentication requirements, or rate limits. Does not explain what 'recent' means or the format of the logs, lacking essential behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences with no filler. The main action is front-loaded ('Get recent logs'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and four parameters, the description is too minimal. It does not explain the return format, how to interpret logs, or how this tool relates to other log tools. For a debugging tool, more context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all four parameters are documented in the input schema. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get recent logs from macOS system' specifying the resource (logs) and action (get). Differentiates from device/simulator log tools by mentioning 'macOS system', but does not explicitly distinguish from siblings like search_logs or stream_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Says 'Use for debugging macOS apps', providing a usage context. However, it does not specify when not to use this tool or suggest alternatives like search_logs or stream_logs, which is needed given the number of sibling log tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs filtered by severity level (fault, error, warning, info, debug)
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | Log level to filter by | |
| process | No | Filter by process name | |
| maxLines | No | Maximum log lines (default: 200) | |
| lastMinutes | No | How many minutes of logs to fetch (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only mentions severity level filtering but omits details about other parameters (process, maxLines, lastMinutes), output format, pagination, or side effects. The tool name suggests it only filters by level, but the schema includes additional filters not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous words. It is front-loaded with the core action and filter criteria.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. It does not explain the return format, how logs are ordered, or defaults for optional parameters. For a tool with four parameters and a potentially large dataset, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear descriptions for all four parameters. The description adds a list of allowed levels, which is already in the enum. It does not add new semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'logs', and the specific filter 'by severity level' with the allowed levels enumerated. It distinguishes from siblings like 'get_logs' which are likely unfiltered, and 'get_device_logs' or 'get_simulator_logs' which filter by device/simulator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools such as 'get_logs' (generic), 'search_logs', 'get_crash_logs', or 'get_vpn_logs'. The description does not mention any prerequisites or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from an iOS Simulator. The simulator must be booted.
| Name | Required | Description | Default |
|---|---|---|---|
| process | No | Filter by process/app name | |
| maxLines | No | Maximum log lines (default: 200) | |
| simulator | Yes | Simulator name or UDID (use list_simulators to find) | |
| lastMinutes | No | How many minutes of logs to fetch (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the booted precondition, but does not mention that the operation is read-only or any other behavioral traits like rate limits or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences (12 words) that front-load the purpose and precondition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple tool. Given the number of sibling log tools, it could be improved by describing the output format or sample usage to ensure correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to add much. It reinforces the simulator precondition but adds no new parameter-level meaning beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets logs from an iOS Simulator, with a specific precondition (must be booted). It distinguishes itself from sibling tools like get_device_logs and stream_simulator_logs by focusing on simulator logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition ('simulator must be booted') and implies context for use, but does not explicitly state when to use this vs. alternatives like get_device_logs or stream_simulator_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs specifically for WorxVPN extension - filters for VPN-related processes
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum number of log lines (default: 300) | |
| lastMinutes | No | How many minutes of logs to fetch (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions filtering for VPN processes but omits details like read-only nature, default parameter values, or that it returns system logs. The parameters are not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the main purpose. However, it could include a brief note on parameters or usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is adequate. It provides the essential purpose and distinguishes from siblings, but lacks details on return format or parameter behavior, which are covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds no extra meaning beyond what is already in the input schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets logs for WorxVPN and filters for VPN-related processes, distinguishing it from generic log tools like get_logs or get_device_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_logs or search_logs. The description does not indicate prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected iOS devices (physical devices connected via USB)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the tool's scope (physical devices via USB) and implies read-only behavior (listing). Lacks details on permissions or failure modes, but for a simple list operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. The essential information is front-loaded and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is sufficient for an agent to understand the tool's purpose and scope. It lacks details on output format or potential errors, but for a simple list operation, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. The description does not need to add param info; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), resource ('connected iOS devices'), and constraint ('physical devices connected via USB'), clearly distinguishing it from sibling tools like 'list_simulators'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing physical iOS devices connected via USB, but does not explicitly state when to use this vs. alternatives like 'list_simulators'. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available iOS Simulators with their state (Booted/Shutdown)
| Name | Required | Description | Default |
|---|---|---|---|
| runtime | No | Filter by runtime (e.g., 'iOS 17', 'iOS 18') | |
| onlyBooted | No | Only show running simulators (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it lists simulators and their state, but does not disclose any destructive behavior, authentication needs, rate limits, or data freshness implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, no fluff. Front-loads the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions returned state. Lacks specifics about other fields (e.g., UDID, name), but given simplicity and sibling context, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and schema descriptions already explain the parameters ('runtime', 'onlyBooted'). Description adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('List') and resource ('iOS Simulators') with output detail ('state (Booted/Shutdown)'). Distinguishes from sibling 'list_devices' which likely lists physical devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like list_devices. Does not mention filtering scenarios or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content of a specific crash report
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | The crash report filename (from get_crash_logs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It only states 'Read', which implies read-only, but does not disclose any behavioral traits such as file size limits, output format, or side effects. This lacks transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to the meaning, and it is very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description explains what it does and the parameter source. However, it omits details about the output format or any constraints, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'filename', and its description 'The crash report filename (from get_crash_logs)' adds valuable context about the source of the value, going beyond the type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'specific crash report', making the tool's purpose unambiguous. It distinguishes from sibling tools like get_crash_logs which list crash reports, and get_logs which handles general logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The parameter description implies that the filename comes from get_crash_logs, suggesting a usage order, but no direct statement or exclusions for other log tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through recent logs for a specific string or regex pattern
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text or regex pattern to search for in logs | |
| maxLines | No | Maximum matching lines to return (default: 100) | |
| useRegex | No | Treat query as a regex pattern (default: false) | |
| lastMinutes | No | How many minutes of logs to search (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only mentions 'recent logs' but does not explain the default time range, rate limits, or that it is a read-only operation. It also does not describe any side effects or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core functionality without unnecessary words. It is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or structure. It also does not specify whether results are full log lines or truncated. However, the tool is simple enough that this gap is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema, so the description adds no extra meaning beyond what is already provided. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches through logs for a string or regex pattern. It uses a specific verb ('search') and resource ('logs'), and distinguishes from siblings like 'get_logs' (fetching without search) and 'stream_logs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_logs' or 'get_logs_by_level'. The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stream live logs for a specified duration. Useful for capturing logs during an action.
| Name | Required | Description | Default |
|---|---|---|---|
| process | No | Filter by process name | |
| durationSeconds | No | How long to stream logs (default: 10 seconds, max: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states duration and filtering, but omits whether the call is blocking, how logs are returned (stream vs batch), or any side effects. Inadequate for a streaming operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core function, second adds a usage example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two optional parameters, the description is adequate but incomplete. It does not explain return format, whether the stream ends automatically, or behavior when filters match nothing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds only the phrase 'for a specified duration', which mildly reinforces durationSeconds but adds no substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'stream', resource 'live logs', and adds contextual use case 'capturing logs during an action'. Distinguishes from siblings like get_logs and search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a vague usage hint ('useful for capturing logs during an action') but no explicit when-to-use or when-not-to-use, nor comparisons to alternatives like stream_simulator_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stream live logs from an iOS Simulator for a duration
| Name | Required | Description | Default |
|---|---|---|---|
| process | No | Filter by process name | |
| simulator | Yes | Simulator name or UDID | |
| durationSeconds | No | How long to stream (default: 10, max: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to state whether streaming blocks, whether it requires a running simulator, if logs are returned incrementally, or what happens after the duration. This is insufficient for a streaming tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous text. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits important context such as whether the tool returns logs as a stream or accumulates them, blocking behavior, and cleanup. No output schema exists, so more detail is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a description. The tool description does not add extra meaning beyond the schema (e.g., no sample values or cross-references to other tools). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Stream', the resource 'live logs from an iOS Simulator', and includes a temporal scope 'for a duration'. It effectively distinguishes from sibling tools like stream_logs (generic) and get_simulator_logs (static logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as stream_logs or get_simulator_logs. There is no mention of prerequisites (e.g., simulator must be running) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stream logs until a pattern is found. Useful for test automation - start an action, then wait for a specific log message.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Text or regex pattern to watch for | |
| process | No | Filter by process name | |
| useRegex | No | Treat pattern as regex (default: false) | |
| timeoutSeconds | No | Max seconds to wait (default: 30, max: 60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the streaming and terminating behavior but does not disclose side effects, rate limits, or the exact stop condition (e.g., does it stop after first match?). The timeout parameter hints at resource management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and follow with a practical use case. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description lacks details on return values (e.g., what is returned when pattern is found?) and error cases (e.g., timeout behavior). It provides minimal but not complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. It does not clarify, e.g., that pattern can be regex or the effect of timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stream' and the resource 'logs', with a specific condition 'until a pattern is found'. It distinguishes from sibling tools like stream_logs (continuous) and search_logs (non-streaming).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives a use case: 'start an action, then wait for a specific log message' for test automation. While it doesn't list when not to use it or provide direct alternatives, the sibling set makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0export_logsget_crash_logsget_device_logsget_logsget_logs_by_levelget_simulator_logsget_vpn_logslist_deviceslist_simulatorsread_crash_reportsearch_logsstream_logsstream_simulator_logswatch_for_patternScored across 14 tools
All tools have clearly distinct purposes: devices, simulators, and various log operations (system, device, simulator, crash, VPN, streaming, search, export, pattern watching). No two tools overlap in functionality.
All tool names follow a consistent 'verb_noun' snake_case pattern (e.g., list_devices, get_logs, stream_logs, search_logs). There is no deviation or mixing of conventions.
14 tools is well-scoped for a console/device management server. It provides a comprehensive set of log retrieval, filtering, streaming, and export operations without being excessive.
The tool surface covers the full lifecycle of log management: listing sources, retrieving logs, filtering, streaming, searching, and exporting. Minor gaps like log deletion or clearing are absent, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
An MCP server that provides congressional transcripts
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
