simctl-mcp-server

by nzrsky

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct simulator operation—device lifecycle, app management, interaction, and settings—with no overlap. Even similar actions like install, launch, and terminate are clearly differentiated.
Naming Consistency5/5
All tool names follow the 'simctl_verb_noun' pattern consistently (e.g., boot_device, install_app, set_location), using lowercase with underscores. The naming is predictable and readable.
Tool Count5/5
With 15 tools, the server is well-scoped for simulator control. Each tool covers a necessary operation without being excessive or sparse, fitting the typical 3-15 range for a focused domain.
Completeness4/5
The tool set covers core device and app lifecycle, plus common interactions like screenshots, push notifications, and privacy control. Missing advanced operations (e.g., device reset, file copy) are minor gaps.
Average 3.6/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions deleting devices and the special 'unavailable' value, but does not discuss irreversibility, permissions, or side effects. Limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, one-line purpose followed by parameter and return description. No wasted words, though slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and output schema, the description covers the parameter's allowed values. However, it omits details like batching behavior or success message format. Adequate but could be more complete.
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 coverage is 0%, so the description adds crucial meaning: it explains that the string array can contain UDIDs, names, or the keyword 'unavailable'. This is valuable beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete simulator devices', specifying the action and resource. It is distinct from sibling tools like simctl_boot_device or simctl_create_device, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. No mention of alternatives or prerequisites. The description is purely operational without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It lists parameters and implies a modification, but fails to mention persistence, side effects on screenshots, or how clearing works. Returns 'Success message' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns, concise at about 10 lines, and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no annotations, the description covers basic semantics but lacks details on default behavior, error handling, or constraints. Output schema exists but is not explained.
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 0% schema coverage, the description adds meaning for each parameter (e.g., 'Time to display (e.g., '9:41')', 'WiFi signal strength (0-3)'). This is helpful beyond the schema's title-only fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Override status bar appearance on a simulator device', which is a specific verb+resource. While it doesn't explicitly differentiate from siblings, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other simulator tools like simctl_screenshot or simctl_ui_appearance. No context on when to use 'override' vs 'clear' action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It mentions wait_for_debugger and console_mode, but does not explain side effects (e.g., app state after launch), error scenarios, or whether the device must be booted. Major behavioral traits like these are missing.
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 a well-structured docstring with a clear one-line purpose, followed by Args and Returns sections. Each sentence provides necessary information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameter semantics adequately, but lacks important context: prerequisites (e.g., device booted, app installed), error handling, and detailed return value. Given the tool's complexity and no output schema, more context would be beneficial.
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%, yet the description provides meaningful explanations for all 5 parameters: device accepts UDID/name/'booted', bundle_id is an identifier, wait_for_debugger is a boolean, console_mode options are listed, and args are additional arguments. This significantly enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Launch an app on a simulator device', which clearly identifies the verb and resource. It differentiates from siblings like install or terminate apps, though it does not explicitly contrast them. The parameter list further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like simctl_install_app or simctl_terminate_app. It does not specify prerequisites (e.g., device must be booted) or contexts where launching is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action and return value ('Success message'), but does not describe side effects (e.g., state saving) or error conditions for already shutdown devices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and uses an Args/Returns structure. It is front-loaded with the action. Minor improvement could be to separate the parameter description into a bullet for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is minimally adequate. It explains the parameter and return value but lacks error handling details and use-case differentiation.
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?
The input schema has no description for the 'device' parameter. The description adds valuable context by specifying that it accepts a UDID, name, or 'booted'. Since schema coverage is 0%, this compensates well.
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 clearly states the action ('Shutdown') and the resource ('simulator device'). It distinguishes from sibling tools like simctl_boot_device and simctl_delete_device by focusing specifically on shutdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use shutdown versus other lifecycle operations. It does not mention prerequisites (e.g., device must be booted) or what to do if the device is already shut down.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the action and returns a 'Success message', omitting side effects, potential failures (e.g., device not found, architecture mismatch), or state changes. This is insufficient for an AI agent to understand tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated first and parameters listed clearly. It avoids unnecessary words, though a slightly more structured format (e.g., separating usage notes) could improve readability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of booting a simulator and the absence of annotations, the description is incomplete. It does not mention prerequisites (e.g., device must exist, Xcode required), error conditions, or the significance of the arch parameter. The return value is vague; even with an output schema, the description should provide more context.
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?
The input schema has 0% description coverage, so the description must add meaning. It explains device as 'UDID, name, or ''booted'' for current device' and arch as 'arm64 or x86_64', which clarifies acceptable values. However, it does not specify the default behavior for arch when omitted, limiting completeness.
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 clearly states the action 'Boot a simulator device', using a specific verb and resource. It effectively distinguishes from sibling tools like simctl_create_device or simctl_shutdown_device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., device existence) or exclusion criteria. However, the name and purpose are sufficiently clear for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Create a new simulator device' without disclosing side effects, error conditions, required permissions, or behavioral details like whether creation overwrites existing devices or requires runtime availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and front-loaded with the main action. It separates Args and Returns, which is clear. However, it could be more concise by integrating parameter descriptions into the main line, and it still leaves room for improvement in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not visible but noted), the description need not detail return values. However, the description lacks completeness for a creation tool: no mention of uniqueness constraints, whether the device is created in a specific directory, or what happens if a device with the same name exists. It feels incomplete for its complexity.
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 coverage is 0%, but the description adds brief explanations for each parameter, including examples for device_type and runtime (e.g., 'iPhone 15 Pro', 'iOS 17.0'). This provides context beyond the schema's type-only definitions, though it could include more format constraints or valid values.
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 clearly states 'Create a new simulator device,' specifying the verb 'create' and resource 'simulator device.' It distinguishes from sibling tools like simctl_boot_device, simctl_delete_device, and simctl_list_devices, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing required arguments but does not explicitly state when to use this tool vs alternatives. No guidance is provided on when not to use it or which sibling might be more appropriate for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a write operation ('Install') but lacks details on side effects, required states (e.g., device booted), error conditions, or idempotency. The minimal description does not sufficiently inform the agent.
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 extremely concise: one sentence for purpose, two lines for parameter descriptions, and one line for the return value. No unnecessary words; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers basic usage and parameter meanings, it omits important context such as preconditions (device must be booted), potential errors, or validation constraints. Given the low complexity (2 simple params, no nested objects), it is adequate but leaves room for improvement.
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?
The input schema has 0% description coverage, but the description provides meaningful context for both parameters: 'device' accepts UDID, name, or 'booted'; 'app_path' is a path to .app or .ipa. This adds significant value beyond the raw schema, fully compensating for the lack of schema descriptions.
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 clearly states the verb 'Install' and resource 'app on a simulator device', distinguishing it from sibling tools like simctl_launch_app (launch) and simctl_terminate_app (terminate). The purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., device must be booted) or conditions to avoid (e.g., app already installed). The description only states the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether recording runs asynchronously, how to stop it, or any side effects. It only mentions a 'Recording start message' as return value.
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 highly concise: a single purpose sentence, an Args block, and a Returns line. No wasted words, and structure is front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 2 required, and no output schema, the description explains all parameters but lacks guidance on how to stop recording, prerequisites (e.g., device must be booted), and handling of the recording process.
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 0%, but the description adds explanations for all parameters: device UDID/name/booted, output path, codec options (hevc, h264), and display options (internal, external). This adds significant value beyond the raw schema.
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 clearly states 'Start recording video of a simulator device', specifying the verb 'record' and resource 'simulator device'. It distinguishes from sibling 'simctl_screenshot' which captures a still image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'simctl_screenshot'. It does not mention prerequisites or context (e.g., device must be booted).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions that the tool returns a success message, omitting important details like whether the simulator must be booted, whether the action triggers a system prompt, or the scope of the 'reset' action.
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 terse and well-structured: a one-line purpose followed by an Args section with each parameter and a Returns line. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is relatively simple, the description could be more complete. It does not explain what constitutes a valid service (e.g., a list or pattern), how the bundle_id affects behavior, or the response format beyond 'success message'. An output schema exists but is not shown; the description's return note is minimal.
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?
The schema has 0% description coverage, but the description adds significant meaning: it specifies the format of device (UDID, name, 'booted'), enumerates actions (grant, revoke, reset), lists example services (photos, camera, etc.), and indicates bundle_id is optional. This goes well beyond the bare schema definitions.
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 'Control app privacy permissions on a simulator device' clearly specifies the verb (control) and resource (privacy permissions on a simulator). It is distinct from sibling tools like simctl_boot_device or simctl_install_app, which cover different functionalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but does not explicitly state when to use this tool versus alternatives. It implies usage for granting, revoking, or resetting privacy permissions, but lacks guidance on prerequisites (e.g., app must be installed) or exclusions (e.g., not for physical devices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly identifies the tool as a write operation (sending a notification) and notes that bundle_id is optional. However, it does not disclose potential side effects, whether the device must be booted, or any security implications.
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 very concise: a single-sentence purpose, followed by a clear argument list and return type. Every sentence adds value; no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and an output schema, the description covers the basics. However, it omits important details like required payload format (Apple Push Notification service) and the fact that the simulator must be booted. The output schema may provide some return info, but the description only says 'Success message'.
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?
The description adds meaning beyond the schema: it specifies that device accepts 'UDID, name, or 'booted'', payload is a 'JSON object', and bundle_id is 'target app bundle identifier (optional)'. This clarifies intent beyond the schema's titles and types.
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 clearly states the action: 'Send a push notification to a simulator device.' It uses a specific verb ('Send') and resource ('push notification to simulator device'), which distinguishes it from sibling tools that handle device management, app installation, or launching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or conditions such as requiring a booted simulator or specific permissions. The description only lists parameters without context on appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It describes the actions but omits important context such as whether the simulator must be booted, what happens if the device is invalid, or if setting location affects running apps. The description lacks transparency about side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear Args and Returns sections. It is slightly verbose but each sentence adds value. It could be more concise by combining some parameter explanations, but overall it is efficient and easy to scan.
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?
Given the tool's complexity (5 parameters with conditional requirements) and lack of annotations, the description covers parameter behavior and return value adequately. However, it lacks completeness on error handling, prerequisites (e.g., device must be booted), and an explanation of the 'run' action beyond scenario requirement. An output schema exists but is not described.
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?
The schema has 0% description coverage, so the description must compensate. It does so excellently by explaining each parameter's meaning (e.g., 'device: Device UDID, name, or 'booted' for current device') and specifying which parameters are required for each action (e.g., 'latitude: required for set action'). This adds essential semantics beyond the raw schema.
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 clearly states the tool's purpose: 'Set or clear device location on a simulator.' It uses a specific verb ('set or clear') and resource ('device location on a simulator'), which distinguishes it from sibling tools that perform other simulator actions like booting, creating, or installing apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists possible actions (set, clear, run) but provides no explicit guidance on when to use this tool versus alternatives. While the sibling tools are distinctly different, the description could clarify when to use each action or mention prerequisites like needing a booted device. Usage is only implied through parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'list' and 'states', implying a read-only operation, but does not explicitly confirm non-destructiveness or mention side effects. The term 'available' is ambiguous without clarification of scope (all devices vs booted only).
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 extremely concise: a one-sentence purpose followed by clearly labeled Args and Returns sections. Every sentence adds value, and the purpose is front-loaded.
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?
Given the presence of an output schema, the description need not detail return structure, but it still mentions 'List of available simulators'. It lacks context about prerequisites (e.g., Xcode runtime) and what states entail, but is sufficient for an agent to understand the tool's role among action-oriented siblings.
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 coverage is 0%, so the description compensates by explaining format (json/text default) and filter (with examples). This adds useful meaning beyond the schema's type and defaults, though the exact allowed values for format could be more precise.
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 clearly states the tool lists iOS simulators and their states, using a specific verb and resource. It is distinct from sibling tools which are all actions (boot, create, delete, etc.), making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., before acting on a device) but does not explicitly state when to use or when not to use this tool. No alternatives or exclusions are mentioned, leaving guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the return is a success message but doesn't disclose whether the screenshot overwrites existing files, what happens if the device is not booted, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear 'Args' and 'Returns' sections. Every sentence serves a purpose, and there is no redundancy.
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?
For a simple screenshot tool, the description covers the essential aspects. It explains parameters and return value. It could mention output file behavior or that the device must be booted, but overall it is adequate.
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 coverage is 0%, so the description provides the only parameter explanations. It describes each parameter (device, output_path, format, display) and indicates defaults (png, internal), adding value beyond the bare schema.
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 clearly states the tool's purpose: 'Take a screenshot of a simulator device.' It uses a specific verb-resource combination and distinguishes from sibling tools like simctl_boot_device or simctl_record_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 or prerequisites. The description is straightforward but lacks context like requiring a booted device or mentioning that output_path must be writable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 correctly describes the tool as a getter/setter but does not disclose any behavioral details like side effects, error conditions, or requirements (e.g., whether the simulator must be booted). The description is adequate for a simple tool but not comprehensive.
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 very concise: three sentences with an 'Args' section and a 'Returns' line. It is front-loaded with the core action and avoids any superfluous information. Every sentence earns its place.
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?
Given the tool's simplicity (2 parameters, output schema exists), the description is fairly complete. It covers parameter semantics and return value. However, it could be slightly more explicit about the output format (e.g., 'Current or updated appearance as a string') and any constraints (e.g., 'only works on booted simulators').
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 0%, so the description must add meaning. It does so by explaining that 'device' can be a UDID, name, or 'booted', and that 'appearance' can be 'light' or 'dark' (or null for get). This adds significant context beyond the bare type definitions in the input schema.
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 clearly states 'Get or set UI appearance (light/dark mode) on a simulator device,' providing a specific verb ('get or set') and resource ('UI appearance on simulator device'). It distinguishes itself from sibling tools like simctl_screenshot or simctl_status_bar_override, which deal with different aspects of the simulator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains basic usage: providing 'device' is required, and 'appearance' is optional (if omitted, returns current appearance). However, it lacks explicit guidance on when to use this tool versus alternatives, and does not mention any preconditions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the basic action and return value but lacks details like termination behavior (forceful, loss of unsaved data) or prerequisites (app must be running).
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 concise (6 lines), front-loaded with purpose, and every sentence adds value without redundancy.
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?
Given the tool's simplicity (2 params, no nested objects), the description covers core aspects: purpose, parameters, and return. It could mention that the device must be booted and app installed, but overall it is adequate.
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?
The Args section explains that 'device' can be UDID/name/'booted' and 'bundle_id' is the app identifier, adding meaning beyond the schema's type-only definitions. However, no further specifics (e.g., how to obtain bundle_id) are provided.
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 starts with a clear verb 'Terminate' and specifies the resource 'app on a simulator device', differentiating it from sibling tools like simctl_launch_app and simctl_install_app.
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 context is clear: use this tool to stop a running app. However, no explicit when-not-to-use or alternative tools are mentioned, which would have improved guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![simctl-mcp-server MCP server](https://glama.ai/mcp/servers/nzrsky/simctl-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/nzrsky/simctl-mcp-server)

Score Badge

Copy to your README.md:

[![simctl-mcp-server MCP server](https://glama.ai/mcp/servers/nzrsky/simctl-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/nzrsky/simctl-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nzrsky/simctl-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server