phantom-touch

by hieudtr8

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., pt_launch_app vs pt_list_apps). However, pt_type_text and pt_fill_input both handle text input, and pt_list_elements vs pt_list_inputs have some overlap, though descriptions clarify their specific use cases.
Naming Consistency5/5
All tools consistently use the pt_ prefix with verb_noun snake_case naming (e.g., pt_boot_simulator, pt_get_clipboard, pt_list_inputs). The pattern is predictable and uniform across the entire set.
Tool Count4/5
18 tools is on the higher end for simulator automation, but each tool covers a distinct operation (simulator control, app management, interaction, input). The count feels slightly heavy yet justified for the comprehensive feature set.
Completeness4/5
The server covers core simulator workflows: controlling simulators, launching apps, UI interaction, text input, and screen inspection. Missing features like device orientation or push notification simulation, but these are secondary and do not block primary automation tasks.
Average 4/5 across 18 of 18 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 carry the full behavioral burden. It states the action but does not disclose side effects, error handling for non-running simulators, or whether the operation is reversible. The minimal wording leaves behavioral traits underexplained.
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, direct sentence that is appropriately sized. Every word carries meaning without filler 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?
For a simple tool with one parameter and no output schema, the description is mostly adequate. However, the lack of behavioral transparency and usage guidance makes it not fully complete for an agent to know edge cases and proper invocation 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?
The input schema fully documents the udid parameter with 100% coverage, so the description does not need to add parameter details. The description itself adds no extra meaning 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 'Shut down a running iOS simulator' uses a specific verb and resource, clearly distinguishing it from sibling tools like pt_boot_simulator and pt_launch_app. The action 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. There is no mention of prerequisites (e.g., the simulator must be booted) or contrast with pt_boot_simulator or pt_terminate_app.
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 must carry the burden. The word 'Read' explicitly signals a non-mutating operation, which covers the read-only aspect. However, it does not disclose edge cases like empty clipboard handling or whether retrieval is limited to plain text, leaving some ambiguity.
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 of ten words, front-loaded with the action 'Read the current contents'. It is immediately scannable and free of unnecessary details.
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 the schema covering parameters, the description is mostly complete. However, without an output schema or explicit mention of return type, an agent might not know exactly what to expect (e.g., a string, null if empty), but this is a minor gap for a simple getter.
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 fully documents the single optional 'udid' parameter with a description explaining it uses the active device when omitted. The tool description adds no parameter-specific information, but since schema coverage is 100%, the baseline 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 uses the specific verb 'Read' with resource 'clipboard/pasteboard', clearly distinguishing it from the sibling write tool pt_set_clipboard. It leaves no ambiguity about the tool's function.
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 or how it relates to alternatives. It does not mention conditions like 'use this to retrieve clipboard content before asserting text' or contrast with pt_set_clipboard. Usage must be inferred entirely from the name and simple wording.
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 must carry the full burden. It indicates a non-mutating 'Get' operation, which is correct, but it does not disclose error conditions, requirements for an active simulator, or behavior when the UDID is invalid. Given the simplicity of the tool, the lack of detail is somewhat acceptable, but additional context would improve transparency.
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 unnecessary words. It efficiently conveys the tool's purpose and output format, making it easy for an agent to quickly understand.
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 explains what the tool returns (width and height in pixels) and the schema covers the optional parameter. It lacks a note about error cases or prerequisites like needing a booted simulator, but for a trivial read-only getter, this is a minor gap. Overall, the description is complete enough for the tool's simplicity.
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 covers the single optional parameter 'udid' with 100% coverage, explaining its default behavior. The description does not add any parameter-specific information, but the schema already provides sufficient semantics, so the baseline 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 uses the specific verb 'Get' and clearly identifies the resource as 'screen dimensions (width and height in pixels) of the simulator.' This is distinct from sibling tools like pt_swipe or pt_launch_app, and the inclusion of pixel units adds precision.
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 about when to use this tool versus alternatives. While there are no direct equivalents among siblings, the description does not mention preconditions such as requiring a booted simulator or how to best utilize the returned dimensions. The agent must rely on the name and parameter schema to infer usage.
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 the burden of disclosing behavioral context. It merely restates the action of pressing a button without mentioning side effects, requirements, or return behavior. For a tool that simulates physical button presses, additional context such as the need for a booted simulator or potential system actions would improve transparency.
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 redundant words. It is front-loaded with the core action and immediately gives the relevant button examples. This is appropriately sized for the tool's simplicity.
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 tool is simple, with one required enum parameter and one optional string, fully documented in the schema. The description is sufficient for an agent to understand the tool's purpose and invoke it, although it does not mention prerequisites like simulator state or output. Given the lack of an output schema and the simplicity of the action, the description is reasonably complete.
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 contains descriptions for both udid and button (100% coverage), so the description does not need to add parameter meanings. The description lists some button values but omits SIDE_BUTTON; however, the schema's enum is complete. The description adds no new parameter semantics beyond the schema, so a baseline 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 the verb 'Press' and the resource 'hardware button on the simulator', listing example buttons. This distinguishes it from sibling tools like pt_swipe, pt_tap, and pt_type_text which deal with other interaction types. The purpose is unambiguous and specific.
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 the tool is for pressing hardware buttons but provides no explicit guidance on when to use it versus alternatives. There are no mentions of preconditions or exclusions, and no sibling tool alternatives are referenced. This is minimal guidance, resulting in an implied usage level.
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 only states the action ('Set the clipboard content') without revealing that it overwrites existing clipboard content, requires a simulator, or has any side effects. This is minimal transparency for a mutating tool.
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 concise sentences, front-loaded with the core function ('Set the simulator's clipboard/pasteboard content') followed by a brief use-case note. Every word earns its place, with no redundant or vague phrasing.
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 setter tool with two parameters and full schema coverage, the description adequately conveys purpose and typical usage. It lacks details like return value or side-effect warnings, but these are minor for this tool's complexity and are partially inferable from the action verb.
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 fully documents both parameters (text and udid) with clear descriptions, so the schema covers 100% of the parameter semantics. The description adds no additional parameter-level insight beyond a general use context, aligning with the baseline score of 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 states a specific verb ('Set') and resource ('simulator's clipboard/pasteboard content'), making the tool's function unambiguous. It naturally distinguishes itself from sibling tools like pt_get_clipboard (read vs write) and pt_type_text (clipboard vs direct text input).
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 phrase 'Useful for preparing text to paste into fields' provides a concrete usage scenario, implying the tool is a setup step for pasting. However, it does not explicitly state when to prefer this over alternatives like pt_type_text or pt_fill_input, nor does it mention any prerequisites (e.g., booted simulator).
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 explicitly states 'force close', conveying the destructive/immediate nature. However, it does not disclose potential side effects (e.g., unsaved data loss) or that it operates on simulators only, which the schema hints at via the 'udid' parameter.
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, front-loaded sentence with zero wasted words. Every part 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?
For a simple 2-parameter tool with no output schema, the description is largely sufficient. However, it omits the simulator-specific context (visible in the schema) and any mention of return values or failure behavior. Still, it is complete enough for the core action.
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 the schema already documents both 'udid' and 'bundleId' clearly. The description adds no extra parameter meaning beyond 'a running iOS application'.
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 ('Terminate (force close)') and identifies the resource ('a running iOS application'). This clearly distinguishes it from sibling tools like pt_launch_app or pt_list_apps.
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 pt_launch_app, pt_press_button, or pt_shutdown_simulator. The description simply states what it does without exclusions or prerequisites.
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 adds the prerequisite that the simulator must be booted, but does not disclose other behavioral details such as what happens if the app is already running or if the app is not installed.
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 exactly two sentences, front-loading the purpose and following with the key prerequisite. No redundant 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?
For a simple launch tool, the description covers the essential purpose and prerequisite, and the schema fully documents both parameters. The lack of output schema or annotations means some runtime behavior is unstated, but it is sufficient for basic 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's example bundle ID adds some clarification, but largely duplicates the schema's parameter descriptions and does not provide substantial extra meaning.
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 iOS application using its bundle identifier, with a concrete example. This distinguishes it from sibling tools like pt_terminate_app or pt_open_url, which have 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: the simulator must be booted first. However, it does not explicitly mention alternatives or when-not-to-use conditions, such as using pt_boot_simulator if not booted or pt_open_url for URLs.
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 full burden. It discloses the read-only nature ('List'), the 'visible' scope, and the output fields, which is helpful. However, it omits details such as whether hidden elements are excluded, whether the UI hierarchy is flattened, or any prerequisites like an active app—acceptable but not deeply transparent.
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 verb and object, then a direct usage hint, then output details. Every sentence contributes 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?
For a simple list tool with one optional parameter and no output schema, the description adequately conveys what the tool returns and its purpose. It could be slightly stronger by explicitly noting that it returns all elements including interactive inputs, especially given the sibling pt_list_inputs, but it remains sufficient for selection.
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 sole parameter (udid) has a clear description in the schema (100% coverage), so the description adds no additional parameter semantics. The baseline of 3 applies because the schema already handles parameter meaning.
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 ('List'), resource ('UI elements'), and scope ('on the current screen'), with specific output details (types, labels, values, coordinates). It is immediately distinguishable from siblings like pt_tap or pt_type_text, which perform actions rather than list elements.
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 explicitly says 'Use this to find elements to tap or type into,' providing a clear usage context. It does not mention exclusions or alternatives, but within the sibling set, it is the obvious tool for discovering available UI elements before interacting.
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 supplied, so the description carries the full disclosure burden. It accurately conveys that a swipe gesture is performed, but does not add behavioral details such as coordinate origin, gesture speed, or potential system interactions beyond the schema's duration note.
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 action, and contains no redundant words or information that duplicates the schema.
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 simple nature and the complete parameter schema, the description provides sufficient information about purpose and usage. It does not describe return values (no output schema), which is acceptable. Minor missing context like coordinate origin is not critical.
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 all parameters with descriptions (100%), so the description adds no additional parameter semantics; it only generically refers to 'one point to another', which is already represented by x_start/y_start/x_end/y_end.
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 ('Swipe') and the target ('the screen'), and provides common use cases (scrolling, dismissing, navigating) that differentiate it from sibling tools like pt_tap and pt_type_text.
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 explicitly says 'Use for scrolling, dismissing, or navigating between screens', giving clear when-to-use context. It does not mention alternative tools directly, but the sibling names (pt_tap, etc.) provide implicit alternatives.
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 full burden. It discloses a key behavioral trait: the booted simulator becomes the active device for subsequent commands. This goes beyond merely restating the tool's name and provides useful side-effect information, though it does not cover edge cases like already-booted simulators or failure conditions.
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, each adding essential information. The first sentence states the core action, and the second explains the important side effect. There is no filler or redundant 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?
For a single-parameter tool with no output schema, the description is nearly complete. It covers the operation and its impact on subsequent commands. It does not mention prerequisites like using pt_list_simulators to find the UDID or error handling, but these are not critical for basic invocation. Overall, it provides sufficient context for correct 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 fully describes the 'udid' parameter (100% coverage), and the description repeats 'by its UDID' without adding new meaning. The parameter semantics are adequately covered by the schema, so baseline 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 uses the specific verb 'Boot' with the resource 'iOS simulator' and specifies the input mechanism 'by its UDID'. It clearly distinguishes from sibling tools like pt_shutdown_simulator and pt_launch_app by focusing on the simulator booting action.
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 phrase 'becomes the active device for subsequent commands' clearly indicates the intended usage: boot a simulator before running other simulator-dependent commands. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.
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 full burden of behavioral disclosure. It explains the internal mechanism (walks fiber tree, calls onChangeText callback) and lists requirements, which is helpful. However, it omits potential failure behaviors (e.g., what happens if the identifier is not found, multiple matches, or if the input is uncontrolled) and does not describe return values or timeouts. This is adequate but not rich.
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 well-structured and front-loaded. The first sentence states the core purpose, followed by a bolded reliability claim, then clearly labeled REQUIREMENTS and identifier matching details. Every sentence contributes useful information without padding, and the use of headers improves scannability. Appropriate length for a tool with prerequisites.
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, the description covers key contextual aspects: purpose, how it works, prerequisites, and match criteria. It does not explain error handling or return values, and there is no output schema to clarify results. Still, it is mostly complete for invoking the tool correctly, with minor gaps around edge cases.
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 100%, so the baseline is 3. The description adds value beyond the schema by specifying that the identifier is matched case-insensitively and as a partial match against accessibilityLabel, testID, or placeholder. This extra semantic detail improves understanding of the 'identifier' parameter beyond the schema's brief example.
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 and resource: 'Fill a React Native TextInput by connecting to the Hermes debugger via CDP.' It distinguishes itself from siblings by emphasizing it is the 'MOST RELIABLE method for filling React Native controlled TextInput fields,' which differentiates it from pt_type_text or pt_tap.
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 strong usage context by listing explicit requirements: Metro dev server running, app in dev mode, and the TextInput rendered on screen. It implies when to use this tool (for controlled TextInputs) via the 'MOST RELIABLE' claim, but it does not explicitly mention alternative tools or warn against using it for non-controlled inputs. This is clear context but lacks explicit exclusions or named alternatives.
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 transparency burden. The verb 'List' strongly implies a read-only operation, and it discloses the output fields (bundle IDs and display names). It does not undermine any safety expectations or hide 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, focused sentence that conveys the tool's purpose and output without any redundant or extraneous content. Every word contributes meaning.
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 read-only list operation with one optional parameter, the description is nearly complete: it states the action, the target (simulator apps), and the returned data (bundle IDs and display names). It could note whether a booted simulator is required, but this is reasonably implied.
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, 'udid', is fully described in the schema ('Simulator UDID (uses active device if not specified)'), achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline of 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 ('List') and clearly identifies the resource ('all installed apps on the simulator') and the output ('bundle IDs and display names'). This distinguishes it from sibling tools like pt_list_simulators and pt_list_elements.
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 clearly states its purpose, so usage context is evident: use this when you need to see installed apps and their identifiers. It does not explicitly discuss alternatives or exclusions, but no strong need exists given the clear scope.
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 burden and does well: it discloses the internal mechanism (connects via CDP, walks fiber tree, finds onChangeText) and the return fields (name, placeholder, accessibilityLabel, testID, current value). It stops short of describing failure modes or prerequisites, but the core behavior is clearly communicated.
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 compact and well-structured: a clear purpose statement, a mechanism explanation, and a usage pointer. Every sentence earns its place with no filler 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?
The description explains what the tool does, how it works, what it returns, and when to use it—all in a few sentences. It lacks an explicit prerequisites statement (e.g., Hermes debugger must be active) but this is implied by the mechanism. The absence of an output schema is compensated by listing return fields.
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% for the single metroUrl parameter, which has a default and description. The tool description adds no extra semantic detail about the parameter beyond what the schema already provides, so the baseline score of 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 opens with a specific verb and resource: 'List all TextInput components currently rendered in the React Native app.' It clearly distinguishes from siblings like pt_list_elements by narrowing to TextInput components with onChangeText, and explicitly links to pt_fill_input.
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 explicit usage guidance in the final sentence: 'Use this to discover which inputs are available before calling pt_fill_input.' It names an alternative (pt_fill_input) and a clear workflow, though it does not explicitly state 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 the full burden of explaining behavior. It discloses that the action occurs on the simulator and gives examples of web pages and deep links, but it does not mention side effects like whether it brings an app to foreground, what happens if the scheme is not handled, or if it clears current state. The behavior is largely predictable, but additional transparency would be beneficial.
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, two sentences, and front-loaded with the action. The example is relevant and adds value without unnecessary length. Every sentence contributes to understanding the tool's purpose and usage.
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 tool is simple with a clear schema and no output schema, so the description adequately covers the main use cases. It explains web pages and deep links, which is sufficient for an agent to select and invoke it correctly. However, it does not mention edge cases like URL encoding or the need for apps to register the scheme, which could be considered a minor gap.
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 100% for both parameters, so the baseline is 3. The description adds meaningful context for the 'url' parameter by illustrating deep link format ('myapp://screen/profile'), which helps the agent understand expected input semantics beyond the schema's simple 'The URL or deep link to open'.
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 and resource: 'Open a URL or deep link on the simulator.' It distinguishes itself from siblings like pt_launch_app by explicitly mentioning deep links into apps and web pages in Safari, using a concrete example.
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 context on when to use this tool: for opening web pages in Safari or triggering deep links. It implies the alternative (launching apps directly via bundle ID would use pt_launch_app) but does not explicitly name alternatives or state when not to use it, leaving a slight gap.
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?
No annotations are provided, so the description must disclose behavior. It states the action (takes a screenshot), the return format (base64-encoded PNG), and the context (current simulator screen). While it doesn't mention potential side effects or timing, none are expected for a screenshot tool, and the description covers the essential 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 two sentences with no redundant information. The first sentence states the primary action, the second clarifies the output format and usage, making it front-loaded and highly efficient.
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—one optional parameter, no output schema—the description fully covers the essential information: what it does, what it returns, and when to use it. Slight ambiguity about the exact 'screen' scope does not detract from overall completeness for a tool of this complexity.
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 full coverage of the only parameter (udid) with the description 'Simulator UDID (uses active device if not specified),' which explains optionality and default behavior. The tool description adds no additional parameter semantics, 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.
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: 'Take a screenshot of the current simulator screen' with a specific verb and resource. It also distinguishes itself from sibling tools by being the only screenshot-related tool, and mentions the output format (base64-encoded PNG).
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 with 'Use this to see what's currently displayed on screen,' which implies when to use it. It does not explicitly mention alternatives or exclusions, but among the sibling tools there is no competing screenshot tool, so the guidance is adequate for selection.
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 of behavioral disclosure. It states the core action (tap) and implies a one-time screen interaction. The instruction to use pt_list_elements first adds workflow context. It does not mention the duration parameter's effect (long press), but that is already documented in the schema, and the description's simplicity matches the tool's straightforward 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 concise, consisting of exactly two sentences. The first sentence states the function, and the second provides a practical usage hint. There is no redundant or verbose content; every sentence earns its place, making it highly efficient.
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 (4 parameters, 2 required, no output schema), the description is mostly complete. It clearly identifies the action and provides a necessary workflow pointer. It does not explain the optional udid or duration, but the schema covers these fully. The description could mention the long press capability, but it's not a critical omission for an agent selecting 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 baseline is 3. The description mentions x and y coordinates but does not add any additional meaning beyond the schema's own descriptions. The optional parameters (udid, duration) are not addressed in the description, but the schema fully explains them, so the description adds no extra semantic value.
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: tapping on the screen at specified (x,y) coordinates. It uses a specific verb ('Tap') and resource ('screen'), which distinguishes it from sibling tools like pt_swipe (swipe) and pt_list_elements (list elements). The purpose is unambiguous and directly tied to the tool's name and parameters.
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 explicit guidance to use pt_list_elements first to obtain coordinates before tapping. This tells the agent the recommended workflow and prerequisite step. However, it does not explicitly mention when not to use this tool or compare with alternatives like pt_swipe, though the distinct action type implies this.
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 transparency burden and adequately discloses the output (list with UDID, name, state, runtime version) and scope ('all available'). It does not mention side effects, but listing is inherently read-only and safe; the description avoids ambiguity.
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 sentences: the first front-loads the action and fields, the second gives practical advice. No extraneous wording, perfectly sized for the tool's simplicity.
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 zero parameters and a simple list output, the description sufficiently covers the tool's purpose, expected return contents, and placement in a workflow. It doesn't elaborate on output formatting or edge cases, but such detail is not essential for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making parameter description unnecessary. Schema coverage is trivially 100%, and the description accurately reflects that no inputs are required, so a baseline of 4 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 lists all available iOS simulators with specific fields (UDID, name, state, runtime version). It unambiguously distinguishes itself from sibling tools like boot, shutdown, or launch actions by focusing on enumeration.
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 instruction 'Use this first to find a simulator to work with' provides explicit when-to-use guidance and implies it precedes other simulator operations. It does not explicitly name alternatives or exclusions, but none are necessary given the tool's simple listing role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paste and keyboard strategies, their trade-offs, and React Native compatibility. It also mentions auto-tap focusing, which is important behavioral context beyond what the schema provides.
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 front-loaded with the main purpose, followed by structured strategy blocks and a concise important note. Every sentence is actionable and there is no wasted 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 tool has 6 parameters and no output schema or annotations. The description covers usage flow, strategy selection, and focus behavior, but omits explicit return/error handling and does not mention sibling alternatives like pt_fill_input. Still, it is reasonably complete for a typing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all six parameters, so the baseline is 3. The description adds meaningful context for x/y coordinates (auto-tap to focus) and strategy (recommended vs faster but incompatible), which elevates it above the baseline.
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 types text into the currently focused field or after tapping a field, using a specific verb and resource. It distinguishes from sibling tools like pt_tap by focusing on text entry, even though it doesn't explicitly name alternatives.
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?
Provides clear guidance on when to use the paste vs keyboard strategy, with a strong recommendation for React Native apps. It also explains the coordinate auto-tap behavior, but does not explicitly contrast with sibling tools like pt_fill_input or state when not to use this tool.
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:

[![phantom-touch MCP server](https://glama.ai/mcp/servers/hieudtr8/phantom-touch/badges/card.svg)](https://glama.ai/mcp/servers/hieudtr8/phantom-touch)

Score Badge

Copy to your README.md:

[![phantom-touch MCP server](https://glama.ai/mcp/servers/hieudtr8/phantom-touch/badges/score.svg)](https://glama.ai/mcp/servers/hieudtr8/phantom-touch)

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/hieudtr8/phantom-touch'

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