Skip to main content
Glama
conorluddy

XC-MCP: XCode CLI wrapper

by conorluddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Suggest Best Simulator

simctl-suggest
Read-onlyIdempotent

Ranks iOS simulators for your project using project history, recent usage, device popularity, and boot performance. Provides transparent scoring and reasoning for each suggestion.

Instructions

simctl-suggest

Intelligent simulator suggestion tool.

Overview

Suggests the best simulators for your project based on project preferences (remembered from previous successful builds), recently used simulators, device popularity (iPhone 16 > iPhone 15), and boot performance metrics. Transparent scoring algorithm shows reasoning for each recommendation.

Parameters

Required

None - all parameters are optional

Optional

  • projectPath (string): Project directory for project-specific ranking

  • deviceType (string): Filter suggestions by device type

  • maxSuggestions (number, default: 4): Maximum number of suggestions to return

  • autoBootTopSuggestion (boolean, default: false): Automatically boot top suggestion

Returns

Ranked suggestions with scores, reasoning, boot history, performance metrics, summary of scoring criteria, and guidance for next steps. Each suggestion includes simulator name, UDID, state, availability, score breakdown, and boot performance data.

Examples

Get project-specific suggestions

await simctlSuggestTool({
  projectPath: '/path/to/project'
});

Auto-boot top suggestion

await simctlSuggestTool({
  projectPath: '/path/to/project',
  autoBootTopSuggestion: true
});

Filter by device type

await simctlSuggestTool({
  deviceType: 'iPhone',
  maxSuggestions: 3
});

Related Tools

  • simctl-boot: Boot suggested simulator

  • simctl-list: See all available simulators

  • simctl-health-check: Validate environment health

Notes

  • Scoring algorithm (100 point scale): Project preference (40), Recent usage (40), iOS version (30), Popular model (20), Boot performance (10)

  • Project-aware: Remembers preferred simulator per project

  • Performance metrics: Learns boot times and reliability from usage

  • Popularity ranking: Suggests popular models (iPhone 16 Pro > iPhone 15)

  • Transparent scoring: Shows reasoning for each recommendation

  • Auto-boot option: Optionally boots top suggestion immediately

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceTypeNo
projectPathNo
maxSuggestionsNo
autoBootTopSuggestionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A3.9/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true and destructiveHint=false, but the description includes an 'autoBootTopSuggestion' parameter that boots a simulator – a state-changing action. This directly contradicts the readOnlyHint. The description also mentions learning from usage and remembering preferences, implying persistent side effects. This is a severe contradiction.

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?

Well-structured with clear sections (Overview, Parameters, Returns, Examples, Related Tools, Notes). The overview is front-loaded, examples are practical, and every line adds value. No redundancy or filler.

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?

Since there is no output schema, the description adequately describes return values, scoring breakdown, and next steps. It covers all parameters, examples, and related tools. However, the annotation contradiction on auto-boot leaves ambiguity about the tool's side effects, which slightly undermines completeness.

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 coverage is 0%, so the description carries the full burden. It explains each parameter (projectPath, deviceType, maxSuggestions, autoBootTopSuggestion) with descriptions and defaults, and provides varied examples showing usage. This fully compensates for the bare schema and adds clarity beyond it.

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 states a specific verb and resource: 'Suggests the best simulators for your project'. It clearly distinguishes from siblings like simctl-list (listing all simulators) and simctl-boot (booting a specific simulator), making it easy for an agent to know this is the suggestion tool.

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 description provides examples for different use cases (project-specific, auto-boot, device type filter) and lists related tools. However, it does not explicitly state when NOT to use this tool versus alternatives (e.g., 'use simctl-list when you want a raw list'). The context is clear but exclusions are only implied.

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

Deploy Server

Other Tools