rn-sim-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
While many tools are distinct, there is notable overlap between screenshot tools (screenshot vs sim_screenshot_hires vs snapshot_ui) and UI inspection tools (ui_describe_all vs snapshot_ui, ui_find_element vs rn_component_tree). Descriptions clarify intent, but an agent could easily misselect between tools that appear to perform similar actions.
Naming Consistency2/5
Tool names follow inconsistent patterns: some use domain prefixes (rn_, ui_, sim_), some are bare verbs (build, launch, stop, test), and structures vary between verb_noun (build_run_sim, launch_app_sim) and noun_phrase (sim_screenshot_hires, rn_component_tree). This mix makes the naming chaotic and unpredictable.
Tool Count3/5
24 tools is at the heavy end, but the server aggregates functionality for Xcode builds, RN debugging, and UI automation, so each tool has a purpose. The count is justified but feels somewhat bloated due to overlapping screenshot and inspection tools.
Completeness4/5
The tool set covers the full lifecycle for React Native iOS simulator work: building, running, testing, launching, stopping, UI interaction, component/styles inspection, and layout auditing. Minor gaps exist (e.g., no explicit reset or uninstall tool), but core workflows are well-supported.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral context. It provides no detail beyond the verb 'list', no mention of output format, filtering, 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 a single concise sentence with no unnecessary words. It is front-loaded with the purpose and wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple tool, the description is incomplete. It lacks any explanation of the 'enabled' parameter, return value, or usage context, and there are no annotations or output schema to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional boolean parameter 'enabled' with no description, and the description does not mention it. Schema description coverage is 0%, and the description does not compensate.
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 the tool lists iOS simulators, which is specific and a read operation. It does not explicitly differentiate from sibling tools, but the action is distinct enough that ambiguity is low.
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. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'Capture screenshot' without mentioning whether the operation is read-only, what platform or device it targets, or any side effects. This is a minimal disclosure that fails to explain what happens or what constraints exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it is under-specified for a tool with a parameter and sibling alternatives. While there is no waste, it is not appropriately sized because it lacks necessary context, making it more of an under-specification than a well-structured concise description.
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?
The tool is simple, and the schema covers the parameter, but the description omits critical context such as the target environment (simulator/device), how it differs from sim_screenshot_hires, and what the screenshot contains. Given the sibling tools, this context is essential for proper selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including an enum and description of 'returnFormat.' The description adds no extra semantic value, so the baseline of 3 is appropriate.
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 the action: 'Capture screenshot.' It uses a specific verb and resource, so the basic purpose is clear. However, it does not differentiate from the sibling tool 'sim_screenshot_hires,' which also captures screenshots but in a specific context, so it lacks sibling differentiation.
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 like sim_screenshot_hires or snapshot_ui. There is no mention of intended scenarios, prerequisites, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of disclosing behavioral traits. The single sentence 'Test on iOS sim' reveals nothing about side effects, prerequisites, what happens to the simulator, or output format. It does not even state if it builds first, requires a pre-built app, or how results are reported.
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 extremely concise, consisting of a single sentence. It contains no filler or redundant information, and the key components (test, iOS sim) are present. However, it is so brief that it lacks useful elaboration, though conciseness itself is not over-penalized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the test workflow, how parameters like xctestrunPath fit together, or what a typical invocation looks like. The context is insufficient for an agent to correctly use the tool without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 80%, meaning most parameters already have descriptions. The tool description adds no parameter semantics beyond the schema, but this is acceptable given the high coverage. The baseline of 3 applies because the schema handles the parameter documentation adequately.
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 'Test on iOS sim' clearly indicates the tool runs tests on an iOS simulator, using an imperative verb and a specific resource. It distinguishes from sibling tools like build_sim and launch_app_sim, which serve different purposes. However, it lacks specificity about the type of test (unit vs UI) and could be more explicit.
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 like build_run_sim or launch_app_sim. The description only states what it does, not the context or prerequisites. There is no mention of when to choose this over other testing or build tools.
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 carries the full burden of disclosing behavioral traits. It only states that it searches and returns elements, but does not mention that it is a read-only operation, whether it affects the simulator state, or what happens on no-match. This lack of safety and side-effect information is a critical omission for a tool invoked by an AI 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 a single sentence, immediately stating the action and target. It is front-loaded and contains no fluff beyond the harmless '[ios-simulator-mcp]' prefix. All words contribute meaning, making it highly efficient and easy to parse.
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 tool's complexity (5 parameters, no output schema, no annotations), the description is too sparse. It does not explain the return format, potential errors, or how the 'udid' parameter interacts with the search. The schema covers parameter semantics, but the description fails to provide the behavioral and environmental context an agent needs to safely and effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameters are fully documented with descriptive text. The tool description adds no extra meaning beyond 'given criteria', which is already implied by the schema. Per the baseline rule, this scores a 3; the description doesn't enhance parameter understanding but doesn't hinder it either.
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 the tool's core function: searching the accessibility tree and returning matching elements. It uses a specific verb ('Searches') and resource ('accessibility tree'), which distinguishes it from interaction tools like ui_tap or ui_type. However, it doesn't explicitly differentiate from ui_describe_all, which also inspects the UI, so it falls short of a perfect score.
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. The description does not mention any exclusions, prerequisites, or recommended contexts. With sibling tools like ui_describe_all and ui_tap available, the agent is left to infer when to choose this tool, which is a significant gap.
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 carries the full burden of behavioral disclosure, but it only says 'Stop sim app.' It does not explain whether the app is terminated gracefully, whether it is uninstalled, whether user data is preserved, or what happens if no app is running. This is minimal disclosure for an action-oriented tool.
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 a single concise sentence with no filler content. The '[XcodeBuildMCP]' prefix provides context, though it is a minor distraction. For a simple zero-parameter tool, the length is appropriate, though 'sim app' could be expanded slightly for clarity without losing conciseness.
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 tool's simplicity (zero parameters, no output schema), the description is nearly sufficient, but it omits important behavioral context such as the scope of 'stop' (e.g., does it stop all running instances?) and any side effects. The presence of sibling tools like 'launch_app_sim' helps, but the description itself leaves room for ambiguity.
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 tool takes zero parameters, so there are no parameter semantics to document. The schema has no properties, and the description adds no parameter-related details, but this is not a gap because there is nothing to parameterize. A baseline score of 4 is appropriate for a parameterless tool.
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 uses a specific verb ('Stop') and a resource ('sim app'), making it clear the tool terminates a simulator app. It is distinguishable from sibling tools like 'launch_app_sim' and 'build_run_sim.' However, 'sim app' is somewhat abbreviated and could be more explicit (e.g., 'app on the iOS Simulator').
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?
There is no guidance on when to use this tool versus alternatives. The name suggests it is the inverse of 'launch_app_sim,' but the description does not state that or mention any preconditions like needing a running app. The intended use is only implied by the tool name and sibling context.
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 carries the full burden for behavioral transparency. It only says 'Swipe on the screen' without disclosing coordinate system details, duration behavior, or any effects of the swipe. Key behavioral aspects such as swipe granularity and default duration are left to the schema, making the description insufficient on its own.
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 a single, clear sentence with no unnecessary words or repetition. It is concise and front-loaded with the action, though it could be argued that the brevity borders on under-specification rather than deliberate conciseness.
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?
The tool has 7 parameters, 4 required, and no output schema. The description gives no usage guidance, no coordinate system explanation, and no indication of return behavior. This is insufficient for an agent to fully understand invocation context and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% descriptive coverage for all seven parameters, so the baseline score is 3. The description adds no parameter-specific semantics beyond what the schema already provides, so no additional credit is warranted.
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 uses the specific verb 'Swipe' with the resource 'the screen in the iOS Simulator', clearly distinguishing it from sibling tools like ui_tap and ui_type. It unambiguously states what the tool does.
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 gives no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states the action without any contextual cues.
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 is minimal. It does not disclose any behavioral details such as requiring a project or workspace path, potential side effects, or output format. The agent is left to infer all behavior from the name and schema.
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 a single concise sentence with no fluff. It is front-loaded with the tool's purpose, but it could be slightly more informative without much cost. Overall, it is efficient.
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 list tool, the description is adequate but minimal. It does not explain the relationship between the two optional parameters, nor what the output looks like (no output schema exists). While not incomplete, it leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for projectPath and workspacePath, so the baseline is 3. The description adds no additional semantic meaning beyond the schema, such as when to use one parameter over the other.
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 function: 'List Xcode schemes.' It uses a specific verb ('List') and resource ('Xcode schemes'), which distinguishes it from sibling tools like list_sims (list simulators). The intent 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 is provided on when to use this tool versus alternatives, or how to choose between projectPath and workspacePath. The tool name and description imply its use, but there is no explicit context or exclusions.
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 burden. It discloses useful behavior: styles are merged across the component chain, and StyleSheet.create styles surface as registeredStyleId. However, it does not address error handling, side effects, or the meaning of bundleId, leaving gaps in 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?
The description is concise with a front-loaded first sentence. The second sentence adds a technical detail about registeredStyleId, though the metaphor 'computed-styles panel React Native never had' is non-essential and could be trimmed without losing meaning.
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?
Without an output schema, the description partially explains expected results (resolved styles/props, registeredStyleId) but omits details about output structure, error behavior, and the optional bundleId. It is adequate for a simple inspection tool but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; testID is described but bundleId has no description in either the schema or the tool description. The description focuses on testID but does not explain bundleId's role or how it affects the resolution, failing to compensate for the low coverage.
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 the tool resolves style and props for a given testID, with a specific verb ('Resolved') and resource. It distinguishes itself as a computed-styles tool among siblings, though it doesn't explicitly contrast with alternatives. The metaphor partially obscures but doesn't mislead.
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 for inspecting computed styles for a single testID, but provides no explicit guidance on when to use it over sibling tools like rn_component_tree or rn_eval. There are no exclusions or alternative references.
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 carries full responsibility for behavioral disclosure. It only states the basic tap action, but omits behaviors implied by optional parameters such as duration (long press), udid targeting, and any side effects or results. The description is too minimal for a tool with additional configurable behavior.
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 single, clear sentence with no filler words. The prefix '[ios-simulator-mcp]' provides context and every word earns its place. It is appropriately concise.
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?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It does not explain optional behaviors like duration, how to select a simulator via udid, or what the tool returns. A basic tap is understood, but the full context of usage is missing given the richer parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters, achieving 100% coverage, so the baseline is 3. The tool description adds no parameter meaning beyond the schema. However, the schema contains a notable typo (the description for 'y' says 'The x-coordinate'), which the tool description does not correct, so no added clarity is 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 clearly states the tool's action ('Tap') and resource ('the screen in the iOS Simulator'), which is a specific verb+resource combination. It distinguishes from sibling tools like ui_type and ui_swipe by indicating a precise interaction type.
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. It does not mention exclusions, prerequisites, or scenarios where tapping is appropriate versus other UI interactions. Sibling tools like ui_type and ui_swipe are distinct but no comparative guidance is given.
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 carries the full burden of disclosing behavior. It only states the input action and does not reveal side effects, whether text replaces or appends, targeting requirements, or error behavior.
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 single sentence with no filler, front-loading the core action. Every word serves a purpose.
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?
For a tool with no annotations and no output schema, the description is too thin. It omits crucial operational context such as needing a focused text field, simulator boot state, and how udid selection works when omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('Text to input', 'Udid of target...'), so the baseline is 3. The description itself adds no extra parameter semantics beyond what the schema already provides.
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 'Input text into the iOS Simulator' with a specific verb ('Input') and resource ('iOS Simulator'). This distinguishes it from sibling tools like ui_tap and ui_swipe, which perform different UI actions.
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 given on when to use this tool versus alternatives, nor any prerequisites. The description implies usage (typing text) but does not explain when to choose it over ui_find_element or ui_tap, or mention required simulator state or focus.
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 carries the full burden of behavioral disclosure. It mentions the side effect of making a specified profile active, but does not explain whether unspecified settings are merged or replaced, what 'session defaults' entail, or any safety or persistence implications beyond the schema's persist parameter. This is a significant gap for a mutation tool.
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 a single concise sentence with no wasted words, but it lacks structured detail given the tool's complexity (20 parameters). It is efficient but could benefit from a more structured breakdown of key behavior or parameters.
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?
This is a complex tool with 20 parameters and no output schema. The description does not explain the concept of session defaults, how profiles work, the effect on other tools, or what the tool returns. It is too minimal for the complexity, making it incomplete for an agent to fully understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema provides decent parameter documentation. However, the description adds no parameter-specific meaning, and several parameters (arch, scheme, deviceId, useLatestOS, suppressWarnings) lack descriptions in the schema. The description does not compensate for these gaps, so a baseline 3 is justified.
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 a specific action: 'Set session defaults' for the active profile or a specified profile. It distinguishes from the sibling tool 'session_show_defaults' by focusing on setting rather than showing, making the purpose 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 by mentioning setting defaults for either the active profile or a specified profile, but it does not explicitly state when to use this tool over alternatives or provide context on prerequisites or expected workflow. The guidance is minimal, so a score of 3 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?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It mentions returning 'a number' but does not clarify what that number represents (e.g., boolean, distance, or confidence), nor does it state side-effect-free behavior or error handling. The defaults for axis and tolerance are only in the schema, not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences with no fluff, and the core purpose is front-loaded in the first sentence. The second sentence adds a helpful conceptual metaphor without unnecessary 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?
There is no output schema, so the description must explain the return format. Saying 'with a number' is vague and does not specify whether the output is a boolean flag, a measurement, or an aggregate value for multiple elements. This gap makes it difficult for an agent to correctly interpret results, especially since the tool lacks sibling differentiation in usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces parameters like 'axis' and 'tolerance' by mentioning 'on an axis' and 'within a tolerance', but it does not add new meaning beyond the schema's own descriptions. Ids are implicitly referenced as 'given elements', adding no extra detail.
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 checks whether elements share an edge along an axis within a tolerance, using the plain-English phrase 'are these on the same line' to convey the intent. It distinguishes itself from sibling tools like ui_layout_audit by focusing specifically on alignment checks rather than general layout inspection.
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 for verifying visual alignment of UI elements, but it doesn't explicitly state when to prefer this over alternatives or how to interpret the result in a broader workflow. No exclusions or typical call scenarios are provided, leaving the when-to-use guidance largely 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?
No annotations are provided, so the description carries the full burden. It discloses one important behavior: runtime logs are captured automatically and the log file path is included in the response. However, it does not mention prerequisites (e.g., a booted simulator), whether the app is terminated first, or any side effects. Some useful context is added, but significant gaps remain.
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 two short sentences, with the main action front-loaded and the logging behavior added succinctly. No wasted words; every sentence earns its place.
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 tool has two optional parameters, no output schema, and no annotations. The description covers the core action and a key return detail (log path), but it omits usage context (when to launch vs. build_run_sim) and prerequisites (like simulator state). For a simple launch tool, it is partially complete but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (env and launchArgs) have descriptive text, including the SIMCTL_CHILD_ prefix note for env. The description itself adds no parameter-specific information, so the schema does the heavy lifting, meeting the baseline for high coverage.
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 launches an app on a simulator, which is a specific verb+resource. It distinguishes itself from sibling tools like build_run_sim (which builds and runs) and open_sim (which opens the simulator) by focusing solely on launching an app. The second sentence about log capture adds a useful distinguishing feature.
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. It does not mention that it should be used after building an app, or that build_run_sim could be used to build and launch in one step. No exclusions or alternative tool references are given.
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. The verb 'describes' strongly implies a read-only operation, but the description does not disclose the output format, whether the simulator must be booted, or any other behavioral nuances beyond the intrinsic meaning.
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?
A single sentence that is front-loaded with the action and context. Every word earns its place; the '[ios-simulator-mcp]' prefix adds useful namespace context 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?
With no output schema and no annotations, the description should clarify what the agent will receive back. It states the content type ('accessibility information') but not the format or structure, nor does it provide usage context relative to sibling tools. Adequate for a simple read tool but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter (udid) is fully documented, including the IDB_UDID env var fallback. The description adds no additional parameter semantics, so the baseline 3 applies.
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 uses a specific verb ('Describes') and resource ('accessibility information for the entire screen in the iOS Simulator'), clearly distinguishing it from sibling tools like ui_find_element that target specific elements or ui_layout_audit that audits layout.
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 explicit guidance on when to use this tool versus alternatives. While 'entire screen' implies a global overview, it does not state exclusions, prerequisites, or name alternative tools for more targeted queries.
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 provided, the description partially carries the behavioral burden. It explains that the snapshot becomes stale after UI changes and must be refreshed, which is useful. However, it does not disclose the output structure, side effects, or any limitations beyond staleness.
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 a single dense sentence that front-loads the core purpose and packs in usage guidance. It is efficient but slightly run-on, and the unusual 'rs/1' phrase adds ambiguity. Overall, every phrase earns its place.
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 optional parameter and no output schema, the description covers the main workflow and refresh behavior. However, because there is no output schema, it would benefit from explicitly describing the snapshot format or the contents (e.g., the list of elementRefs) to fully prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'sinceScreenHash' is fully described in the input schema (100% coverage), so the description does not need to add parameter details. Baseline of 3 applies because the schema provides complete semantics and the description offers no additional param context.
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 uses a specific verb ('Capture') and states the resource ('semantic rs/1 runtime UI snapshot with elementRef targets'). It clearly differentiates itself from sibling UI tools by emphasizing elementRef targets and the snapshot/observation role, not just describing the UI.
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 gives clear context: use the snapshot once, then use tap for a single target or batch for multiple same-screen targets, and refresh after navigation, scrolling, sheet changes, or layout changes. It implies when to use and when to refresh, though it does not explicitly name alternative tools or when not to use.
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 behavioral disclosure burden. It states the compile-only nature and the absence of a launch, which is the core behavior. However, it omits other potentially relevant details like side effects (e.g., DerivedData changes), prerequisites (e.g., an available simulator), or what exactly is produced.
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 single short sentence with the tool/action front-loaded. Every word adds value—the scope ('iOS sim') and the key constraint ('compile-only, no launch') are included with zero waste.
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 basic build tool, the core function is clearly conveyed, and the schema covers two of three parameters. However, with no annotations, no output schema, and the description not addressing `buildForTesting`/`testProductsPath` usage scenarios or any environmental requirements, the overall context remains somewhat incomplete though adequate for simple use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (67%), with `buildForTesting` and `testProductsPath` already described in the schema. The description itself adds no parameter-level detail; `extraArgs` remains undocumented both in the description and schema, but the high schema coverage justifies a baseline 3.
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 specifies a clear verb ('Build') and resource ('iOS sim'), with an explicit scope modifier '(compile-only, no launch)' that distinguishes it from the sibling `build_run_sim`. This gives an unambiguous purpose.
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 parenthetical '(compile-only, no launch)' clearly signals when to use this tool: when a build without launching is desired. It does not explicitly name the alternative `build_run_sim`, but the exclusion is evident from the 'no launch' phrase, providing clear context with no misleading guidance.
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 provided, the description carries the burden. It discloses an important prerequisite (dev build with Metro) and implies a read-style operation, but does not mention output format, default filtering behavior (onlyTestIds defaults to true), or potential performance impacts. It adds some context beyond the bare name but lacks richer behavioral detail.
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?
Three short sentences, each earning their place: purpose, usage workflow, and prerequisite. Front-loaded with the core function, no fluff or 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?
The tool has 4 optional parameters and no output schema or annotations. The description covers purpose and prerequisite but does not describe the response shape or default behavior (e.g., that it returns rows keyed by testID, or that includePath adds ancestor chains). It is minimally viable but lacks some contextual detail an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add much parameter-level information; it only hints at the testID focus ('keyed by testID') which loosely relates to onlyTestIds. The schema already covers each parameter, so the description doesn't need to compensate.
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: it returns React components on screen keyed by testID. It also clarifies the primary use case ('Start here to find which component owns an element'), distinguishing it from sibling tools like rn_styles and rn_eval.
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?
It gives explicit usage context: 'Start here to find which component owns an element, then call rn_styles.' This establishes a clear workflow and names a follow-up tool. It also notes a prerequisite ('Requires a dev build with Metro running'). It doesn't explicitly list when-not-to-use or alternative tools, but the directional guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It reveals two important behavioral traits: it only works in dev builds and that returned app data must be treated as untrusted instructions. This goes beyond the basic operation and provides critical safety guidance about a powerful tool. It does not detail error handling or side effects, but the key behavioral risks are addressed.
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 two sentences, front-loaded with the primary purpose, and includes a necessary safety warning. Every clause is informative, with no redundant or filler content.
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 and lack of output schema, the description covers the essential aspects: what it does, the dev-only requirement, and a security warning. It does not explain the optional bundleId or return value structure, but for a straightforward eval tool, the description is adequate. It is not overburdened, yet could benefit from a bit more context on bundleId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what is in the schema. Schema coverage is 50% because bundleId lacks a description, and the tool description does not clarify its purpose or usage. The expression parameter's description in the schema is adequate, but the overall parameter semantics are not enhanced by the tool description.
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 evaluates a JavaScript expression in the running app, using a specific verb ('Evaluate') and a clear resource ('JavaScript expression inside the running app'). It also notes 'Dev builds only,' which is a distinctive context. No sibling tool appears to offer this functionality, so it is well differentiated.
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?
It provides a clear usage context by explicitly stating 'Dev builds only,' which tells the agent when this tool is applicable. It does not mention exclusions or alternatives, but given the absence of a sibling eval tool, the context is sufficient. The security note about treating returned data as untrusted also serves as a usage caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool will boot the simulator if needed, install and launch the app, automatically capture runtime logs, and include the log file path in the response. This discloses key side effects and response behavior beyond what annotations would provide. However, it does not mention prerequisites like a project/scheme or what happens on build failure, so it's not exhaustive but still strong.
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 three short sentences, each earning its place: the main action, the log-capture behavior, and the preferred usage context. It is front-loaded with the core purpose and contains no redundant or filler content.
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?
The description covers the tool's purpose, side effects, response contents (log file path), and when to prefer it. Given the moderate complexity of the tool, two optional parameters, and no output schema, this is nearly complete. It could mention failure handling or default setup requirements, but the essential information for an agent to select and invoke the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters (extraArgs and launchArgs) clearly described as build settings vs. app launch arguments. The tool description adds no additional parameter-specific semantics beyond what the schema already provides, so the baseline 3 applies.
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 action: 'Build, install, and launch on iOS Simulator, booting it when needed.' This is a specific verb+resource combination that distinguishes it from siblings like build_sim (build only) and launch_app_sim (launch only). The phrase 'Preferred single-step run tool' further sets it apart as a combined build+run workflow.
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 a clear usage condition: 'Preferred single-step run tool when defaults are set.' This tells the agent when to prefer this tool over alternatives, implying it should be used for building and launching in one step when default settings are configured. It doesn't explicitly list alternatives or exclusions, but the sibling tool names and the 'preferred' phrasing give enough guidance for most scenarios.
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 bears the full burden. It discloses the tool reports currently attached targets, implying a read-only snapshot, but doesn't discuss output format, empty results, or side effects. For a zero-param query tool, this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences: the first defines what the tool does, the second gives exact usage guidance. Every word contributes, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with no output schema, the description fully covers the agent's needs: what it returns and when to call it. No additional context is required.
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 tool has zero parameters with an empty schema (100% schema coverage). The description doesn't need to add parameter detail, and the baseline of 4 for no params applies.
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 identifies the tool's purpose as showing Metro CDP debug targets currently attached, which is clear despite lacking an imperative verb. It distinguishes from siblings by framing it as a first-step diagnostic for rn_ connection issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call this first when any rn_ tool reports no connection.' This is a precise, actionable trigger condition that stands on its own.
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 safety/behavior disclosure burden. It adds the behavioral context of being a required precursor and warns against assuming defaults are set, but does not explicitly state that it is read-only or describe possible side effects, which is a gap given the absence of annotations.
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 two sentences, front-loaded with the primary purpose, and includes essential prerequisite context without any fluff. The 'XcodeBuildMCP' prefix is minor noise but does not detract from overall conciseness.
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 (no params, no output schema) and the clear action, the description covers the essential context. The added note about being required before first build/run/test calls provides valuable operational context, making it reasonably complete for its intended use.
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 tool has zero parameters and 100% schema coverage (empty schema). Per rubric, baseline is 4 when no parameters exist; the description correctly adds no redundant parameter details, so this score is appropriate.
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 function with a specific verb+resource: 'Show current active defaults.' It distinguishes itself from sibling tools like 'session_set_defaults' by indicating this is the read/display counterpart, making its purpose unambiguous.
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 gives explicit when-to-use guidance: 'Required before your first build/run/test call in a session.' It does not explicitly mention alternatives, but the prerequisite context is clear and actionable, which is sufficient for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral aspects: it uses accessibility frames, accounts for hitSlop, checks horizontal overflow, and explicitly contrasts itself with visual inspection ('Arithmetic, not eyeballing a screenshot'). It could add more detail about the return format or prerequisites, but it is transparent about its non-visual, analytical nature.
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—two sentences that immediately convey the tool's purpose, the specific checks performed, and its key differentiator (arithmetic vs. visual). Every word earns its place, with no fluff or repetition.
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 relatively simple tool with two optional parameters and no output schema, the description provides sufficient context for an agent to understand what the tool does. It covers the input semantics and the nature of the audit. However, it does not describe the output format (e.g., list of violations, report style), which is a minor gap given that no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for both parameters (screenWidth and minTapTarget), achieving 100% coverage. The tool description references these concepts (horizontal overflow, minimum tap target, hitSlop) but does not add new semantic information beyond what the schema already states. The baseline of 3 is appropriate, as the description merely reinforces the schema rather than enhancing 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 clearly states the tool's function with a specific verb ('Audit') and resource ('screen geometry from accessibility frames'), listing concrete checks (zero-size elements, tap targets under minimum after hitSlop, horizontal overflow). This distinguishes it from siblings like 'ui_check_alignment' and 'snapshot_ui', making its purpose unmistakable.
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 clear usage context by specifying that the tool performs arithmetic-based auditing rather than visual screenshot inspection, implicitly directing users to choose it when precise geometric verification is needed. However, it does not explicitly mention alternatives or situations where other tools should be used instead.
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 of behavioral disclosure. It states the tool's purpose and notes it isn't required before build_run_sim, but it does not describe potential side effects, prerequisites, or behavior when no simulator is available. It's enough for a simple utility but lacks depth.
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 two short sentences, front-loaded with the action and purpose, and every word earns its place. There is no redundant or filler information.
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 (0 params, no output schema), the description covers the essential purpose and a key usage distinction relative to a sibling. However, it might have mentioned what 'open' implies (e.g., launching Simulator.app) to be fully self-contained, so it falls just short of a 5.
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 tool has zero parameters, and the schema is empty (100% coverage). The description correctly does not discuss parameters, so the baseline of 4 applies.
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 uses the specific verb 'Open' with resource 'simulator frontend' and clarifies its purpose ('for visibility and manual workflows'). It also distinguishes from the sibling tool 'build_run_sim' by stating it is not required before that workflow, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives when to use ('for visibility and manual workflows') and when not to use ('Not required before simulator build-and-run'), naming the specific sibling (build_run_sim) as an alternative. This provides clear guidance beyond just stating the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It discloses the key trait of being full-resolution and lossless, and contrasts with the downscaling behavior of the proxy tool. However, it does not mention any prerequisites (e.g., booted simulator) or side effects, but for a read-only screenshot tool this is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core function, the second provides usage context and a comparison. No wasted words, front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and no output schema, the description is complete for this tool's complexity. It explains the output (PNG file), the method (simctl), the difference from the sibling tool, and when to use it. The optional parameters and defaults are documented in the schema, so the description covers all essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning about the parameters beyond what the schema provides, but it does implicitly reference simulator context ('via simctl'). Since the schema already fully documents both parameters, a score of 3 is appropriate.
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 it produces a 'Full-resolution lossless PNG via simctl, with dimensions', which specifies both the verb (capture) and the resource (simulator screenshot). It explicitly distinguishes from the sibling 'screenshot' tool by noting the downscaling limitation, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: 'Use for any pixel, spacing or colour question'. It also names the alternative ('The proxied screenshot tool') and explains why it is unsuitable for visual QA, giving a clear when-to-use and when-not-to-use directive.
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:

[![rn-sim-mcp MCP server](https://glama.ai/mcp/servers/atz-dsampath/rn-sim-mcp/badges/card.svg)](https://glama.ai/mcp/servers/atz-dsampath/rn-sim-mcp)

Score Badge

Copy to your README.md:

[![rn-sim-mcp MCP server](https://glama.ai/mcp/servers/atz-dsampath/rn-sim-mcp/badges/score.svg)](https://glama.ai/mcp/servers/atz-dsampath/rn-sim-mcp)

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/atz-dsampath/rn-sim-mcp'

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