xctools-mcp-server

by nzrsky

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Tools are clearly separated by domain prefixes (xcodebuild_, xcrun_, xctrace_) and within each group have distinct, non-overlapping purposes. For example, xcodebuild_archive builds a standalone archive while xcodebuild_build compiles the project, and xcrun_find_tool locates a tool versus xcrun_run_tool executes it.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a category prefix and a descriptive verb (e.g., xcodebuild_archive, xcrun_find_tool, xctrace_record). Multi-word verbs are compound but still uniform. No mixing of conventions.
Tool Count5/5
With 15 tools, the set covers the primary Xcode development workflows (building, archiving, testing, running command-line tools, and profiling) without being excessive. Each tool has a defined purpose and the count feels appropriate for the server's domain.
Completeness4/5
The tool surface covers major Xcode operations: building, archiving, testing, SDK queries, xcrun utilities, and Instruments recording. Minor gaps exist, such as missing xcodebuild clean or analyze, and limited xcrun actions (e.g., no simctl), but the core workflows are complete and agents can work around these omissions.
Average 3.4/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions running a tool and returning output but omits critical behavioral traits such as potential side effects, permissions, or error behavior, which is especially important for a command execution 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 very concise and structured with Args and Returns sections. However, it may be too sparse, missing useful details like example usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool executes arbitrary commands, the description lacks important context such as common tools, error handling, and when to use it. The presence of an output schema slightly reduces the need to explain return values, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides basic explanations for each parameter (e.g., 'Name of the tool to run'), which is minimal but does add value beyond the schema's type-only information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a development tool via xcrun, which is a specific verb and resource. However, it does not differentiate from sibling tools like xcrun_find_tool, which could cause confusion for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With siblings like xcrun_find_tool and xcrun_show_sdk_path, explicit usage context would help, but it is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Import a supported file format' without mentioning side effects (e.g., file overwrites), required permissions, or the nature of the return value. The return is vaguely described as 'Import result'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose followed by an Args block. Every sentence serves a purpose, though the Args section could be more compact. No unnecessary details.
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 5 parameters (2 required), no annotations, and no output schema shown, the description covers the core action and parameters but lacks context on when to use, behavioral constraints, and return format. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates with brief parameter explanations (e.g., input_file examples, template as name/path). These add meaning beyond the schema but are shallow (e.g., no details on template sources or instrument constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource 'Instruments trace file', distinguishing it from sibling tools like xctrace_export and xctrace_list. However, it lacks specificity on supported formats, only giving examples in the parameter description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., when to import vs. record or export), and there is no mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'Build' without disclosing behavioral traits like duration, side effects (e.g., generated artifacts), or failure conditions. Minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with well-structured bullet points for arguments. However, the 'Returns' line is redundant if an output schema exists, and space could be used for more value-added content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no annotations, the description covers basic parameter names but lacks depth. No explanation on choosing between mutually exclusive options (project vs workspace) or environment prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides basic parameter explanations (e.g., 'Path to .xcodeproj file'). These add minimal meaning but lack details like allowed values, constraints, or relationships between parameters.
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 an Xcode project or workspace, with a specific verb and resource. It distinguishes from siblings like xcodebuild_archive (archive) and xcodebuild_test (test).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor on how to choose between project/workspace or scheme/target. Missing prerequisites or context for when building is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool exports data but does not disclose behavioral traits such as whether it is destructive, authorization requirements, or error handling. The return value is vaguely described as 'Exported data or success message.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear lead sentence followed by a parameter list. Each sentence serves a purpose, though the parameter descriptions are minimal. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, required input_file, and no annotations, the description is incomplete. It lacks information on error conditions, environment prerequisites (e.g., Instruments installation), and behavioral details like file size limits. The presence of an output schema mitigates the need for return value details, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description provides basic explanations for each parameter (e.g., 'Path to the .trace file to export from'). These add meaning beyond the schema's bare titles but lack details like format constraints or relationships.
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 'Export data from an Instruments trace file,' specifying the verb (export) and the resource (Instruments trace file). This distinguishes it from sibling tools like xctrace_import, xctrace_list, and xctrace_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. Sibling tools exist (e.g., xctrace_import, xctrace_record), but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the use of debug symbols but fails to mention side effects (e.g., file creation), required permissions, or what happens if dSYM is missing. Limited behavioral context beyond the obvious.
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?
Extremely concise, one sentence for the main purpose plus a clear list of parameters. No unnecessary words, all information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return value need not be explained. However, the description lacks usage guidelines and behavioral details. It is minimally adequate for a simple tool but leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds basic meaning to all three parameters (input_file, output_path, dsym_path). However, it could be more detailed (e.g., file format, how output_path defaults). It improves upon the schema but not substantially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Symbolicate' and resource 'trace file', clearly distinguishing it from sibling tools like xctrace_export or xctrace_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The description simply states what it does without any usage restrictions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it lists destinations, but does not disclose any behavioral traits such as side effects, permissions required, or that it is a read-only operation. This lack of transparency is a 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 short and to the point, using a docstring-like format. It could be slightly more front-loaded by stating the core purpose upfront without the Args block, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, 0 required, no enums, output schema exists), the description covers the basics but leaves ambiguity about whether project or workspace is required, and the contradiction regarding scheme being required vs optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It describes each parameter (project, workspace, scheme) with brief explanations, but it claims scheme is required while the schema marks it as optional with a default null. This inconsistency reduces clarity.
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 valid destinations for a project/workspace and scheme. It uses a specific verb and resource, and it distinguishes itself from sibling tools like xcodebuild_build or xcodebuild_test by focusing on destinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide guidance on when to use it versus alternatives (e.g., xcodebuild_list). There is no explicit when-to-use or when-not-to-use context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It only states the action and return value, without disclosing that it runs xcodebuild -showsdks, its nondestructive nature, or that Xcode must be installed.
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 short (two sentences) but the second sentence 'Returns: List of available SDKs' is redundant with the first. Removing it would improve conciseness. Overall, it is still appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with an output schema, the description is minimally adequate. However, it lacks context about prerequisites (Xcode installation), potential errors, or how the SDK list is obtained, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Baseline for 0 parameters is 4; the description does not add any parameter information, but none is needed.
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 'List all available SDKs', using a specific verb and resource. It is unambiguous and distinguishes from sibling tools that build, test, or archive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when-not to use, or comparison with siblings like xcodebuild_list or xcrun_show_sdk_path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only lists arguments and a vague 'Returns Archive result.' No details about side effects, required input combinations, or error conditions are given. The description adds minimal behavioral context beyond the schema itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with only four lines for arguments and one for returns. It uses clear headings (Args, Returns) and front-loads the purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and no annotations are present, the description provides a basic understanding of inputs and purpose but lacks behavioral details, such as handling of concurrent project and workspace inputs, error messages, or archive path format. It is adequate for a simple archive tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining each parameter: 'Path to .xcodeproj file' for project, 'Path to .xcworkspace file' for workspace, 'Scheme name to archive (required)' for scheme, and 'Path where to save the archive' for archive_path. It clarifies that scheme is required despite the schema not marking it as required, which is 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 'Archive an Xcode project or workspace,' which is a specific verb-resource pair. This distinguishes it from sibling tools like xcodebuild_build (build) and xcodebuild_test (test), all of which have distinct actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not specify prerequisites, such as requiring a project or workspace, nor does it mention scenarios where archive is preferred over build or test. The sibling tools are listed but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes a read-only operation without side effects, but does not mention prerequisites (e.g., Xcode required) or error handling. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three lines covering purpose, parameter, and return value. Every sentence is informative and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers the parameter and return. It could mention what the default SDK is (e.g., current Xcode's default), but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides examples ('iphoneos', 'macosx') and explains the default behavior ('uses default if not specified'), adding meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly says 'Show the version of the SDK' with a specific verb and resource. The name distinguishes it from siblings like xcrun_show_sdk_path, but the description does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like xcodebuild_show_sdks or xcrun_show_sdk_path. The description only states the parameter usage, not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as whether recording starts immediately, required permissions, or side effects. Only a minimal return type 'Recording result' is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and a bullet list for parameters. Every sentence adds information without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no annotations, the description covers basic parameter meanings but lacks information on output schema details, error cases, and usage context. Incomplete given the 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?
With 0% schema description coverage, the description adds value by explaining each parameter (e.g., time_limit with examples). However, details like format constraints are missing for some parameters.
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 records an Instruments trace using a specified template. It distinguishes from sibling xctrace tools (export, import, list, symbolicate) by its unique action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like xctrace_export or xctrace_list. No when-not or prerequisite information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to state that the operation is read-only or that inputs must exist, assuming typical inference but insufficient for robust agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences plus Args/Returns stanzas. Every part is valuable, and the key action (list) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the return value type. It omits potential errors or prerequisites but is largely sufficient. An output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds basic meaning by labeling each parameter as 'Path to .xcodeproj file' and 'Path to .xcworkspace file'. However, it does not explain constraints like mutual exclusivity or optionality beyond what schema defaults imply.
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 the tool lists targets and configurations for projects or schemes for workspaces, clearly distinguishing its purpose from sibling tools like xcodebuild_build or xcodebuild_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (listing), but lacks explicit guidance on when not to use or mention of alternatives. It does not clarify that project and workspace are mutually exclusive, leaving room for misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only mentions 'Returns: Test results' without details on execution behavior, side effects, error handling, or output format.
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 Args and Returns sections. Reasonably concise but includes minor redundancy ('required' already implied). Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no annotations, description provides basic explanations but lacks interaction details (e.g., project vs workspace), default behaviors, or usage context. Output schema exists but not displayed.
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 description adds meaning with one-line explanations for each parameter (e.g., 'project: Path to .xcodeproj file'). Adds value beyond schema's type/title.
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 'Run tests for an Xcode project or workspace.' Distinguishes from sibling tools like xcodebuild_build or xcodebuild_archive which have different purposes.
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?
Provides list of arguments with basic descriptions (e.g., scheme is required) but lacks explicit guidance on when to use this tool vs alternatives, or conditions like specifying a destination.
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 burden. It explains the parameter's default behavior and return value, which adds value beyond the schema. However, it does not disclose any permissions or side effects, but for a read-only tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences: one for purpose, one for parameter, and one for return. It front-loads the key information 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?
For a tool with one optional parameter and an existing output schema, the description covers the parameter and return value sufficiently. No additional context is needed for this simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds examples ('iphoneos', 'macosx') and explains the default behavior, which compensates for the 0% schema description coverage. It provides meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show the path to the SDK' with a specific verb and resource. It is distinct from siblings like xcrun_show_sdk_version, but it does not explicitly differentiate itself, which is acceptable for such a simple tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like xcrun_show_sdk_version or xcrun_find_tool. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states the function and return type, but does not mention idempotency, safety, authorization needs, or side effects. A read-only hint is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an Args/Returns block. No extraneous text, front-loaded purpose, and efficiently structured. Every sentence adds value.
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 one parameter and an existing output schema, the description explains the param and return type. It omits potential constraints like requiring Xcode or offline mode, but for a simple list tool this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. 'list_type' is described with allowed values ('devices', 'templates', 'instruments'), adding meaning beyond the schema's bare string type. Could optionally note the default if any.
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 'devices', 'templates', or 'instruments', specifying the verb 'list' and the resource categories. It distinguishes from siblings like xctrace_record (recording) and xcodebuild_list (Xcode build lists) by explicitly naming the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., xcodebuild_list for Xcode-related listings). The description lacks explicit context for selection, such as prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions return of absolute path, but lacks details on error handling (e.g., tool not found) or performance implications. Adequate but minimal.
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?
Description is brief, with separate sections for args and returns, and no wasted words. Efficient and clear.
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 output schema exists, description explains return value (absolute path). Covers main functionality, but could include notes on error behavior when tool not found.
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 description defines tool_name as 'Name of the tool to find' and sdk as 'SDK name to search in', adding meaning beyond the schema's titles and types. Compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the path to a development tool using xcrun, which is a specific verb-resource pair. It distinguishes from siblings like xcrun_run_tool (runs tool) and xcrun_show_sdk_path (shows SDK path).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., when you need a tool's path) with examples, but does not explicitly state when to use this tool vs alternatives like xcrun_run_tool, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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