XC-MCP: XCode CLI wrapper

by conorluddy

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: v3.2.0
Disambiguation4/5
Tool purposes are mostly distinct but there is some overlap among UI automation tools (e.g., accessibility-quality-check vs idb-ui-describe, screenshot vs simctl-io). Descriptions are detailed, helping agents differentiate, but the sheer number of UI-related tools could cause confusion.
Naming Consistency4/5
Most tools follow a prefix-action pattern (simctl-*, idb-*, xcodebuild-*, workflow-*), but there is inconsistency with tools like 'cache', 'persistence', 'rtfm', and 'screenshot' that lack a prefix. Overall, the naming is predictable and readable.
Tool Count3/5
30 tools is on the high side for a well-scoped server. While many are consolidated via operation parameters (reducing atomic operations), the exported tool count feels heavy for an Xcode wrapper. It is borderline but still manageable.
Completeness4/5
The tool set covers the majority of iOS development workflows: build, test, simulator management, UI automation, caching, and workflow orchestration. Minor gaps exist (e.g., no direct code signing management), but overall it is highly comprehensive.
Average 4.5/5 across 30 of 30 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
No annotations are provided, so the description carries the full burden. It describes operations but does not disclose behavioral traits such as whether operations are destructive (e.g., install/uninstall), error handling, or required permissions. For a lifecycle management tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with markdown sections, headers, and examples. It is somewhat verbose due to repeated examples, but each section adds value. It is front-loaded with purpose and overview.
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 complexity of multiple operations and optional parameters, the description is fairly complete. It explains each operation's parameters and provides examples. However, it does not specify return values (no output schema) or error handling, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides detailed parameter explanations for each operation, including examples for arguments and environment. It adds significant meaning beyond the schema for all 6 parameters, including optionality and usage.
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 'Unified iOS app lifecycle management - install, uninstall, launch, terminate.' It specifies the resource (iOS app) and the verb (lifecycle management). The overview and related tools section distinguishes it from siblings like simctl-device and simctl-list.
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?
While the description lists related tools (simctl-device, simctl-list, idb-app), it does not explicitly state when to use this tool versus alternatives. It implies usage for app management but lacks clear 'when-to-use' and 'when-not-to-use' guidance. The structure implies context but no explicit 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 full burden. It explains each operation's parameters and provides examples, but lacks details on side effects, permissions, error states, or what happens on failure.
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 well-structured with headers, code blocks, and examples, but it is verbose. Some repetition could be reduced without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 operations, 7 params), the description covers each operation's parameters and examples. However, it lacks any mention of return values or error handling, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by documenting each operation's parameters and their meanings (e.g., appPath, bundleId, arguments, environment). Nested objects like 'environment' are explained clearly.
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 'Unified IDB app lifecycle management - install, uninstall, launch, terminate.' It specifies the verb and resource, and distinguishes from siblings like simctl-app explicitly mentioned in related tools.
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 'Related Tools' section lists alternatives (e.g., simctl-app, idb-ui-*), providing implicit guidance on when to use this tool. However, it doesn't explicitly state when not to use it, which would improve clarity.
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 details each operation's behavior and parameters, including that enable persists across sessions and disable can clear data. However, it lacks edge-case details like error handling, permissions, or idempotency, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections but is somewhat verbose, repeating parameter details in both parameter lists and examples. While organized and front-loaded, it could be more concise without losing essential 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 no output schema and no annotations, the description covers operations, parameters, examples, and usage guidance. It references a related tool. However, it misses edge cases like error handling, permission requirements, or concurrency behavior, leaving some gaps for a management tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to all four parameters: cacheDir (custom directory), clearData (clear on disable), includeStorageInfo (storage usage details), and operation (enum values explained). Examples further clarify usage.
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 is for cache persistence management with three specific operations: enable, disable, and status. It uses precise verbs and explicitly distinguishes itself from the related sibling tool 'cache' by noting it handles persistence configuration.
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 'When to Use' section provides explicit scenarios for enabling and disabling persistence, such as long-running projects and CI/CD. However, it does not explicitly state when not to use this tool or provide direct alternatives to the sibling tool 'cache', though it is referenced.
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 exist, so the description carries the full burden. It explains behaviors for each operation: list returns a list, describe returns details, focus focuses a window, connect establishes a persistent connection, and disconnect closes it. Side effects like network usage are implied but not detailed, which is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers, sections, and examples. It is somewhat lengthy but front-loads the overview and uses efficient formatting. The 'Related Tools' section is slightly extraneous but helpful.
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 multiple operations, no output schema, and zero schema description coverage, the description covers parameters and return types broadly (e.g., 'List of targets with metadata'). However, it lacks detailed return structure or error handling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It documents each parameter per operation (e.g., state and type for list, udid for describe/focus/connect/disconnect) and includes examples, adding significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'Unified IDB target management' and lists operations (discover, inspect, focus, manage connections). The 'Related Tools' section distinguishes it from siblings like idb-app and idb-ui-tap, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Each operation is explained with context (e.g., connect: 'Establishes persistent gRPC connection... Useful for warming up connections'). The related tools section provides separation, but explicit when-not-to-use is missing, though implied.
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 must disclose behavior fully. It mentions automatic redaction of sensitive data and metadata tracking, but does not explain failure modes (e.g., when no element is focused), side effects, or prerequisites like focus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, headings, emojis, and examples. It is front-loaded with the core purpose. However, it is slightly verbose (repeats redaction info) and could be tightened.
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 has 9 parameters and no output schema or annotations, the description covers behavior, parameters, examples, and related tools adequately. It lacks a detailed return type specification but summarizes the output format sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed meanings for each parameter beyond the schema, e.g., 'text: String to type into focused field', 'key: Special key name', and explains the purpose of optional parameters like actionName and fieldContext. This compensates for the 0% schema description 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 opens with 'Input text and keyboard commands - automated text entry and special key presses for form automation', providing a specific verb and resource. It distinguishes itself from siblings like idb-ui-tap (focusing) and idb-ui-describe (finding coordinates) via the 'Related Tools' section.
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 'Why you'd use it' section clearly lists use cases (form filling, keyboard shortcuts, sensitive data handling) and mentions related tools for alternative actions. However, it lacks an explicit 'when not to use' statement.
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 fully discloses behaviors: enumerates all installed apps, provides structured metadata, converts pipe-separated output to JSON, and indicates auto-detection of UDID. Does not contradict any annotations.
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?
Structured with clear headings and front-loaded summary. Some redundancy (Returns repeats details from Overview) but each section adds value. Could be slightly more concise.
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?
Given no output schema and 3 parameters, the description covers return format (summary counts, arrays), provides examples, and notes about IDB output format. Leaves no major gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Parameters section explains each parameter: udid (auto-detects), filterType (enum values listed), runningOnly (boolean for running apps). Adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List installed applications' and distinguishes it by mentioning 'discover apps available for testing with bundle IDs and running status.' Among siblings like idb-targets, simctl-list, and idb-launch, this tool uniquely focuses on enumerating installed apps.
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 guidance on filtering by install type or running status, and the Related Tools section suggests when to use this tool in conjunction with launching, terminating, or installing apps. However, lacks explicit when-not or alternative comparisons.
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 carries full burden. It explains each operation's behavior (e.g., 'Permanently delete', 'Reset simulator to factory settings', 'clone with complete state preservation'). Missing details on side effects like GUI behavior after boot, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, tables, and code blocks, making it easy to parse. It is slightly redundant, repeating operation details in both example and per-operation sections, but remains clear and organized.
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?
Given the tool's complexity (multiple operations, many parameters) and lack of output schema, the description thoroughly covers each operation, its parameters, and provides examples. Related tools are listed, providing sufficient context for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with per-operation parameter explanations, including defaults and valid values (e.g., deviceId 'booted' or 'all'). The examples provide concrete usage, enhancing understanding.
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's a unified tool for iOS simulator device lifecycle operations, listing specific actions (boot, shutdown, create, delete, erase, clone, rename). It distinguishes itself from sibling tools like simctl-list and simctl-app by focusing on device management.
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 an overview and includes a 'Related Tools' section, suggesting when to use alternate tools (e.g., simctl-list for discovery, simctl-io for screenshots). However, it lacks explicit 'when not to use' guidance.
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 provides good behavioral context: it mentions 1-hour caching, validates Xcode installation and project path before execution, and gives clear error messages. It does not discuss any side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (What it does, Why you'd use it, Parameters, Returns, Examples, Related Tools). It uses markdown headings, code blocks, and bullet points. While a bit lengthy, every part adds value.
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?
The description explains return type (structured JSON), caching behavior, validation checks, and provides examples. For a read-only listing tool without an output schema, it covers all necessary information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful parameter details: projectPath is a path to .xcodeproj or .xcworkspace, outputFormat defaults to 'json' with enum values 'json' and 'text'. Examples reinforce usage. Minor lack: no explanation of text output format.
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 project targets, schemes, and configurations for Xcode projects. It distinguishes from siblings like xcodebuild-build and xcodebuild-test by focusing on discovery and metadata retrieval.
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 includes a 'Why you'd use it' section listing concrete use cases and mentions related tools for context. However, it does not explicitly state when not to use the tool or provide exclusion criteria.
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 full burden. It discloses validation of Xcode installation and graceful fallback to text format for older versions. These are useful behavioral traits, though no side effects or destructive actions are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections and examples, but slightly lengthy. Every sentence adds value, maintaining clarity without unnecessary verbosity.
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 output schema, the description adequately explains the return value: structured JSON with version info and fallback to text. All necessary information for a version retrieval tool is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. It explains both parameters: 'sdk' for querying specific SDKs and 'outputFormat' with default 'json' and enum values. Examples and fallback behavior add context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Xcode and SDK version information' with a specific verb and resource. It distinguishes itself from sibling tools like xcodebuild-showsdks and xcodebuild-list by focusing on version retrieval.
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 'Why you'd use it' section provides clear use cases such as CI/CD validation and environment consistency. However, it does not explicitly state when not to use this tool or mention alternatives beyond related tools.
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?
Despite no annotations, the description thoroughly explains each operation's behavior, input/output, and cache types. It includes examples and return descriptions, though it lacks details on side effects (e.g., clearing cache) or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with headings, sections, and examples. It is detailed but not overly verbose; however, some redundancy exists (e.g., cache types listed in two places).
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?
All four operations are fully documented with parameters, examples, and return descriptions. Related tools are mentioned for context. Despite the absence of output schema, the description adequately covers what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter, including the enum options for operation and cacheType, and the meaning of maxAgeMs/Minutes/Hours. Examples further clarify usage.
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 'Unified cache management' and enumerates all operations (get-stats, get-config, set-config, clear). It distinguishes from sibling tools like list-cached-responses by mentioning them as related tools, showing differentiation.
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?
Each operation is explained with examples and parameter details, providing clear context for when to use each. The 'Related Tools' section offers guidance on alternatives, though it could be more explicit about 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It comprehensively details behavioral traits: returns markdown documentation, handles errors with fuzzy matching and suggestions, explains case sensitivity and parameter behavior, and describes the progressive disclosure pattern. This goes well beyond what annotations would provide.
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 structured with headings, bullet points, and code blocks, but it is excessively long, containing version history and implementation details that are not essential for an agent's immediate usage. While well-organized, it would benefit from trimming to focus on actionable information for the AI agent.
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?
Given the tool's role as a documentation meta-tool, the description is extremely complete. It covers purpose, parameters, examples, error handling, migration paths, categories, implementation details, and benefits. No output schema exists, but the response format is clearly described. All necessary context for correct usage is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage for parameter descriptions. The description adds significant meaning by explaining the optional toolName and categoryName parameters, providing examples, and noting case sensitivity. It adds context on usage patterns but does not explicitly define behavior when both parameters are provided simultaneously, which would elevate it to a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as providing access to comprehensive documentation for all XC-MCP tools. It explicitly distinguishes itself from sibling tools by being the meta-documentation tool, with a specific verb 'rtfm' and resource 'progressive disclosure documentation system'. It explains its role in the ecosystem, making it unmistakable 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on when to use rtfm: to get full documentation beyond concise descriptions, explore categories, and see examples. It includes examples of usage and mentions that it supplements tool descriptions. However, it lacks explicit 'when not to use' guidance or alternatives, though the context implies it is supplementary. Score is 4 due to clear context but absence of explicit exclusions.
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 discloses caching, cache ID expiration (1 hour), auto-registration, and return types. It lacks mention of permissions but is otherwise thorough for a read-only 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 well-structured with sections (advantages, parameters, returns, related tools, notes) but is somewhat verbose. Every sentence adds value, but some redundancy could be trimmed.
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?
Given no output schema, the description explains return values (full device lists, state, capabilities). It covers usage pattern, caching, filtering, and related tools, leaving no obvious gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains all 5 parameters: cacheId required, detailType with enum values, deviceType, runtime, and maxDevices with default. Each parameter's purpose and usage are clearly described.
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 retrieves detailed simulator information from cached list results and implements progressive disclosure. This distinguishes it from sibling tools like simctl-list which returns concise summaries.
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 explains when to use this tool (after simctl-list) and provides advantages like filtering and pagination. It lists related tools but does not explicitly state when not to use or provide exclusions.
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?
No annotations provided, so description carries full burden. It discloses pre-validation of project existence and Xcode installation, structured JSON output with success status, duration, errors, and typical execution time under 3 minutes. No contradictions.
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?
Well-structured with sections, emoji, and examples. Front-loaded with header and purpose. Slightly verbose (e.g., repeated 'structured JSON response') but clear and organized.
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 no output schema and 3 parameters, description covers purpose, parameters, output type, examples, pre-validation, and execution time. Lacks detailed output field list but sufficient for a clean operation.
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 has 0% description coverage, but description adds meaning: projectPath is path to .xcodeproj or .xcworkspace, scheme is build scheme name, configuration is optional with examples (Debug, Release). Examples illustrate usage. Not all parameters are fully detailed (e.g., configuration values), but sufficient.
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 removes build artifacts and intermediate files for Xcode projects. It distinguishes itself from siblings like xcodebuild-build (for building after cleaning) and xcodebuild-list (for discovering schemes), making its purpose unique 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides 'Why you'd use it' with concrete scenarios (resolve build issues, free up disk space, ensure clean builds). References related tools but does not explicitly state when not to use this tool (e.g., if you need to build instead of clean).
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 provided, so description carries full burden. It discloses learning behavior (remembers configs), progressive disclosure (testId for logs), and test-without-building efficiency. Lacks mention of rate limits or error handling, but otherwise thorough.
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 long but well-structured with headings, bullet points, and examples. It is front-loaded with a summary. Every section adds value, though some details could be condensed for an AI agent.
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?
Given the complexity (10 params, no output schema, no annotations), the description is highly complete: covers purpose, usage, parameters, return values (progressive disclosure), examples, and related tools. Missing only minor error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully: it lists all 10 parameters with explanations, defaults, required status, and even cross-refers to sibling tools. Examples in JSON illustrate usage.
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 'Run Xcode tests' (verb+resource) and distinguishes itself from siblings like xcodebuild-build (build) and xcodebuild-get-details (get logs). It specifies unit and UI tests.
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 'Why you'd use it' section lists benefits (smart defaults, metrics, progressive disclosure, filtering) and the 'Related Tools' section provides alternatives. However, it does not explicitly state when not to use this tool (e.g., if only building), though it is implied.
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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: case-insensitive partial matching, returns all matches, only elements with valid coordinates, and performance metrics (~80ms, 5-6x cheaper tokens). It also explains internal workflow (calls idb ui describe-all). This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Overview, Parameters, Returns, Examples, How It Works, Related Tools, Notes). It is front-loaded with the core purpose. While somewhat lengthy, each section provides valuable information and earns its place.
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 output schema, the description fully explains the return format (array with type, label, identifier, coordinates, frame boundaries) and covers the empty array case. It also gives usage context, performance trade-offs, and related tools. The description is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds essential meaning. It explains query as a search term for labels/identifiers and udid as an optional target identifier with auto-detection. Examples illustrate usage. However, it does not specify constraints like allowed characters or format, which would be helpful.
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 finds UI elements via semantic search in the accessibility tree and returns tap-ready coordinates. It distinguishes itself from siblings like screenshot (visual fallback) and idb-ui-describe (full accessibility tree), establishing a unique role.
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 explains when to use (fast semantic search replacing screenshot analysis for complex UIs) and lists related tools with their purposes (e.g., accessibility-quality-check to assess data richness, idb-ui-tap for tapping). It clearly guides selection but does not explicitly 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: velocity validation (>6000 px/sec), coordinate bound checking, profile parameterization with empirically tested metrics, and semantic action tracking. No contradictions with annotations 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 well-structured with headings and bullet points, but overly verbose. Profile details are repeated in the 'Swipe Profiles' section and again in the 'Why you'd use it' list. Some example JSON is redundant (e.g., multiple swipe directions). Could be trimmed without losing clarity.
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?
Given 11 parameters, 1 required, no output schema, and no annotations, the description provides near-complete context: parameter details, JSON examples for every operation/button, return value summary, and empirical profile data. Minimal gaps (e.g., exact return format could be more structured).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 9% (only 'duration' has a description). The description compensates comprehensively: explains operation values, direction semantics, profile defaults/behavior, coordinate space (point vs pixel), buttonType enumeration, and optional parameters (actionName, expectedOutcome). It adds units and example values beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb ('Perform gestures and hardware button presses') and specifies resources ('swipes, scrolls, and device controls for navigation'). It distinguishes itself from sibling tools by explicitly listing related tools (idb-ui-tap, idb-ui-describe) with brief differentiators.
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 'Why you'd use it' section outlines specific scenarios (automate scroll, test hardware buttons, custom paths). The 'Related Tools' section references alternatives, though it does not explicitly state when not to use this tool or provide exclusion criteria.
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?
No annotations are provided, so the description fully bears the burden of transparency. It discloses key behaviors: app must be running, notification delivered immediately, no user interaction needed, payload must be valid JSON with 'aps' dictionary. It also details error conditions (invalid JSON, app not running, etc.) and mentions test context tracking.
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 well-structured with clear sections and examples, but it is quite lengthy. Some sections like 'LLM Optimization' and repeated 'Test Context Tracking' could be condensed. The front-loading of purpose is good, but overall wordiness reduces conciseness.
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 having no output schema, the description fully covers the return value (JSON with delivery status, test context, and guidance). It also explains error handling, common use cases, and advanced testing strategies. For a tool with 5 parameters and significant complexity, the description is extremely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description thoroughly explains all five parameters: udid (from simctl-list), bundleId (app identifier), payload (JSON with aps dict), testName (for test tracking), expectedBehavior (expected app behavior). It provides multiple examples and payload format details, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends simulated push notifications to apps on simulators. It distinguishes itself from sibling tools like simctl-openurl (URL opening) and simctl-launch (app launch) by focusing on push notification simulation with test tracking. The verb-resource combination is precise.
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 comprehensive guidance on when to use the tool, including a testing workflow with sequential steps (launch app, send push, screenshot). It also lists common use cases (delivery testing, deep link navigation, etc.) and error handling scenarios. However, it does not explicitly state when not to use it or mention alternative tools.
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?
Without annotations, the description must disclose behavioral traits. It explains that the tool remembers successful configurations, uses progressive disclosure, tracks build metrics, and returns structured JSON with a buildId for log retrieval. It does not mention any destructive side effects or permissions, but for a build tool, the described behavior is transparent enough.
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 with markdown headings, emojis, and sections for purpose, benefits, parameters, returns, examples, and related tools. It is detailed but efficient, with every section providing necessary information. No redundant content.
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 output schema, the description thoroughly covers input parameters, return value structure, and how to retrieve full logs via another tool. It also mentions related tools and provides examples. For a complex tool with 6 parameters, this description is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, defaults, and examples. Required parameters (projectPath, scheme) are clearly described, and optional parameters (configuration, destination, etc.) include usage context and defaults. The examples demonstrate typical use cases.
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 builds Xcode projects with intelligent defaults and performance tracking. It differentiates itself from siblings like xcodebuild-test, xcodebuild-clean, and xcodebuild-get-details by highlighting its learning capabilities and progressive disclosure.
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 'Why you'd use it' section lists key benefits (smart defaults, progressive disclosure, performance tracking, structured errors) and the 'Related Tools' section provides alternatives for different use cases (e.g., testing, cleaning, logs). While it doesn't explicitly state when not to use this tool, the guidance is sufficiently clear for an AI agent.
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 must disclose behavioral traits. It explains coordinate transformation, validation, support for single/double/long press, and working on simulators/devices. It mentions error handling and verification guidance in returns. However, it does not mention potential side effects (e.g., navigation changes) or failure modes beyond 'error details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, bullet lists, and an example. It is front-loaded with a summary. While somewhat lengthy, every section adds value (parameters, returns, examples, related tools). Minor redundancy in the 'What it does' vs. 'Parameters' sections could be tightened.
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?
Given the tool has 13 parameters, no output schema, and multiple siblings, the description thoroughly covers purpose, usage context, parameter details, return information, and related tools. It also provides an actionable example, making it complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description fully compensates. It explains each parameter's purpose (e.g., applyScreenshotScale for coordinate transformation), defaults (numberOfTaps=1), and provides a usage example. This is critical for an agent to use the tool correctly.
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 specifies the tool's action ('Tap at coordinates on iOS screen') and resource ('iOS screen') with specific gesture types. It distinguishes itself from sibling tools like idb-ui-describe (for discovering elements) and idb-ui-gesture (for swipes), providing a clear unique role.
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 states when to use this tool (e.g., automating UI interactions from screenshot analysis, transforming coordinates, validating bounds, tracking scenarios). It implicitly suggests alternatives by listing related tools (idb-ui-describe, screenshot, idb-ui-gesture) and their purposes.
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?
The description details the automatic optimization process (capture, resize, compress, encode, extract, transform), error handling, token efficiency, coordinate transformation, view fingerprinting, and temp file cleanup. With no annotations provided, the description fully compensates, making behavior highly transparent.
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 extensive but well-structured with clear headers, bullet points, tables, and examples. It is front-loaded with the core purpose. Minor repetition (e.g., token efficiency mentioned twice) but overall concise for the tool's complexity.
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?
Given 6 parameters, no output schema, and no annotations, the description covers all aspects: input, output (base64 image, metadata, elements, transform), error handling, use cases, comparison with siblings, and next steps. It is thorough and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all 6 parameters, including defaults (e.g., size defaults to 'half'), auto-detection for udid, and semantic context for appName, screenName, state. It also explains the size enum values in detail with pixel dimensions and token savings, adding significant 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 explicitly states 'Capture optimized screenshots with inline base64 encoding for direct MCP response transmission,' providing a specific verb and resource. It distinguishes itself from sibling tools like `simctl-io` through a comparison table, making the purpose clear and unique.
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 includes a comparison with `simctl-io` and a 'Common Use Cases' section, offering context for when to use this tool. However, it does not explicitly state when not to use it, though the alternatives are clear. This is strong guidance but not fully explicit on exclusions.
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?
No annotations provided, but the description thoroughly covers behavior: container type access (read-only vs read-write), error handling, return structure, and next steps. It discloses all relevant behavioral traits.
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?
Well-structured with clear sections, examples, and bullet points. Slightly redundant between 'Why you'd use it' and 'Common Use Cases', but every sentence adds value and it is front-loaded.
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?
Given no output schema and no annotations, the description is remarkably complete: covers purpose, all parameters, container types, error handling, examples, and next steps. Leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage, but the description adds full meaning for each parameter: udid source, bundleId format/example, containerType enum with explanations. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves file system path to app container directories on a simulator. It is a specific verb-resource combination and is distinct from siblings like simctl-list and idb-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes 'Why you'd use it' and 'Common Use Cases' sections that clearly define appropriate scenarios. Lacks explicit 'when not to use' or direct alternatives, but the context is clear.
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?
No annotations exist, so description carries full burden. It comprehensively discloses caching (1-hour), progressive disclosure (concise vs full mode), device limiting (default max=5), token overflow prevention, sorting (booted/recent first), and smart filtering. No contradictions.
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?
Description is well-structured with sections (Overview, Parameters, Returns, Device Limiting, Examples, Related Tools, Notes). It is thorough but some may consider it slightly verbose. However, every section adds distinct value.
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?
No output schema, but description explains return in both modes (concise: summary with cacheId; full: limited device list with metadata). Covers all parameters, caching, sorting, and limits. Completely addresses the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully explains all 6 parameters: deviceType (filter by type), runtime (filter by version), availability (with enum and default), outputFormat (enum), concise (toggle summary), max (limit in full mode). Also explains device limiting behavior.
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 lists iOS simulators with progressive disclosure and caching. It distinguishes from siblings like simctl-get-details (retrieve full details via cache ID), simctl-device (manage simulators), and simctl-app (app operations). The verb 'List' and resource 'iOS simulators' are specific.
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 alternatives (simctl-get-details, simctl-device, simctl-app) and notes 'Essential: Use this instead of 'xcrun simctl list''. Examples show typical use cases. It lacks explicit when-not-to-use but provides good context.
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?
No annotations provided, so the description carries full burden. It covers required simulator state, handler registration, URL encoding, error handling, and return format. No contradiction with annotations (none present).
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?
Well-structured with headings, examples, and bullet points. Front-loaded with summary. Some sections like 'Testing Strategies' are extensive but add value; overall efficient for the tool's complexity.
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?
Comprehensive: covers parameters, supported schemes, return values, examples, use cases, important notes, error handling, workflow, and testing strategies. No output schema, so description adequately explains return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description details each parameter: udid (Simulator UDID from simctl-list) and url (examples of supported URLs). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens URLs in a simulator, listing web, deep links, and special schemes. It distinguishes from sibling simctl-* tools by focusing on URL opening, with a dedicated workflow and examples.
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 context for when to use (deep link testing, etc.) and a workflow integrating with sibling tools. Does not explicitly state when not to use or compare to alternatives, but the purpose is unique among siblings.
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?
Since no annotations are provided, the description fully discloses the tool's behavior: it checks 6 areas, returns pass/fail status and actionable recommendations, warns about disk usage over 80%, and validates the entire toolchain in seconds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, examples, and notes, but it is somewhat lengthy. However, each section adds value and the markdown formatting aids readability.
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?
The description is complete: it explains the purpose, what is checked, the output format, and provides usage examples. With no output schema, the description adequately covers what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the baseline is 4. The description confirms no parameters are needed and explains that the tool performs a complete environment check automatically.
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 that the tool performs a 'comprehensive iOS simulator environment health check' and lists the 6 critical areas it checks. It distinguishes from sibling tools like simctl-list and simctl-create by focusing on diagnosis rather than listing or creating.
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 provides explicit guidance on when to use the tool, such as 'Perfect for troubleshooting when operations fail unexpectedly' and 'Use before CI/CD pipeline execution.' It also references related tools for follow-up actions.
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?
No annotations exist, but description thoroughly discloses auto-detection, temp file behavior, video stopping, prerequisite (booted simulator), file permissions, error handling, and return value structure. No contradictions with 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?
Well-organized with clear headings and subheadings. Every section adds value, from parameter details to examples and next steps. Despite length, it remains focused and front-loaded with core functionality.
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?
Given the tool's complexity (8 parameters, no output schema), the description covers parameters, return values, error handling, coordinate transform, and optimization. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description fully explains each parameter's purpose, defaults, and constraints. Goes beyond schema by providing default values and semantic naming details.
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?
Clearly states it captures screenshots or records videos from iOS simulators with optimization. The verb 'capture' and resources 'screenshots' and 'videos' are specific. Implicitly distinguishes from sibling 'screenshot' by adding video and optimization details.
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 common use cases and important notes, but does not explicitly compare with sibling tools like 'screenshot'. However, the detailed feature description implies when to use this advanced tool over simpler alternatives.
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 bears transparency burden. It details the 7-step orchestration, side effects (shutdown, optional erase, boot), and behaviors like handling shutdown failures as non-fatal. It also mentions that intermediate results are internal, which goes beyond basic operational description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with overview, parameters, return values, examples, and rationale. It is somewhat long but each section serves a purpose. Minor redundancy exists (e.g., repeating step sequence in overview and later), but overall it is efficiently organized.
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?
Given 7 parameters, no output schema, and moderate schema coverage, the description compensates fully. It describes the return object structure, provides three examples covering different scenarios, and explains the workflow's advantages. This makes the tool understandable and actionable without relying on external schema details.
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 57% (4/7 parameters described). The description adds meaning via examples and parameter details (e.g., auto-detection for simulatorUdid, default values like false for eraseSimulator). It provides context beyond schema, though not all parameters get equal depth.
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 performs a 'clean slate app installation' with a specific process sequence, and distinguishes itself from siblings like workflow-tap-element (UI interaction) and xcodebuild-build (direct build) via the 'Related Tools' section.
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 'Why Use This Workflow?' section explicitly compares token efficiency and context reduction vs manual calls, and 'Related Tools' lists alternatives for different tasks (e.g., UI interaction after install). This provides clear when-to-use and when-not-to-use guidance.
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?
Discloses internal steps, fallback behavior, non-fatal error handling, and delays. Since annotations are absent, this fully covers behavioral traits without contradiction.
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?
Well-structured with sections, examples, and bullet points, though slightly verbose. Every part earns its place, but could be tightened without losing clarity.
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?
Fully documents return values and provides guidance for a complex workflow with no output schema. Covers all necessary context for effective 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?
Adds value beyond schema: case-insensitive partial matching, default values, and detailed examples. Schema coverage is 100%, so baseline 3; extra examples push to 4.
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's a high-level workflow for tapping UI elements by name, distinguishing it from sibling tools like idb-ui-tap and idb-ui-find-element.
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?
Includes a dedicated 'Why Use This Workflow?' section explaining token efficiency and reduced context pollution, and lists related tools. Explicit guidance on when to use and alternatives.
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?
The description fully discloses that the tool returns only quality scores and counts, not full element details. It specifies execution time (~80ms), token cost (~30 tokens), and the three quality levels, providing complete behavioral transparency beyond the lack 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, tables, and code examples, making it easy to parse. However, it is somewhat lengthy; a slightly more concise version could improve efficiency without losing value.
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 lacking an output schema, the description fully explains return values (quality, recommendation, elementCounts, queryTime, queryGuidance), how it works, and cost comparison. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides clear meanings for both parameters: udid (target identifier, auto-detects if omitted) and screenContext (screen name for semantic tracking). Examples further illustrate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Quick assessment of accessibility tree richness - decide whether to use accessibility or screenshots.' It specifies the verb (assess) and resource (accessibility tree richness) and distinguishes from sibling tools like idb-ui-describe and screenshot.
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 provides explicit guidance on when to use (as a first step before choosing an automation approach), when not to use, and alternatives. It includes cost comparisons, quality levels with recommendations, and examples.
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?
Despite no annotations, the description thoroughly explains behavior: progressive disclosure with caching, automatic NDJSON parsing, filter levels, and iOS-specific field handling. It also covers data quality assessment and performance considerations (token overflow prevention).
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 comprehensive and well-structured with headings, bullet points, and examples. Though lengthy, each section adds value and is front-loaded with a clear summary. Minor verbosity could be trimmed but it's well-organized.
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?
Given the tool's 6 parameters and lack of output schema/annotations, the description provides complete guidance. It covers return values, filter levels, examples, and integration with sibling tools. The progressive disclosure and strategy patterns ensure effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds extensive meaning for all 6 parameters. It explains operation enum values, x/y coordinates for point operations, auto-detection of udid, and filterLevel with detailed explanations. Examples further clarify usage.
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 queries the iOS accessibility tree to discover UI elements, their properties, and coordinates. It distinguishes from sibling tools like idb-ui-tap (tapping) and idb-ui-find-element (semantic search) by focusing on discovery and data quality assessment.
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 describes when to use: discover tappable elements, get precise coordinates, assess data quality, validate tap coordinates. Provides progressive filter escalation and mentions alternatives (e.g., screenshots for minimal data). Also references related tools for further actions.
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?
No annotations provided, but the description thoroughly discloses behavioral traits: it retrieves cached results, uses progressive disclosure to avoid token overflow, and notes cache ID expiration. It also mentions auto-registration with MCP server.
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 with headings, bullet points, and emojis. Every section adds necessary value without redundancy. It is appropriately sized for the tool's complexity.
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 output schema, the description covers return values (tool execution results, filtered logs, metadata). It also includes notes on cache ID expiration and usage, making it complete for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides minimal descriptions, but the description compensates with detailed explanations of each parameter, including the enum values for detailType and default value for maxLines. Schema description coverage is 0%, but the description adds full 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 retrieves detailed build/test output from cached results, implementing a progressive disclosure pattern for logs. It is distinct from sibling tools like xcodebuild-build and xcodebuild-test, which produce the initial summaries.
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 explains when to use this tool (for debugging build failures/test issues) and mentions related tools and requirements (valid cache ID, 30-minute expiration). It also lists alternative tools in the 'Related Tools' section.
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:

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

Score Badge

Copy to your README.md:

[![xc-mcp MCP server](https://glama.ai/mcp/servers/conorluddy/xc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/conorluddy/xc-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/conorluddy/xc-mcp'

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