This is a domain-specialized MCP server (Xcode project manipulation) with 7 tools. All tools have explicit descriptions and schemas with typed parameters. However, there are systematic gaps: (1) most parameter descriptions are minimal (1-2 sentences); (2) no output schemas are documented for any tool, callers cannot predict what shape of data to expect; (3) error handling descriptions are absent, LLMs have no guidance on recovery paths; (4) enum constraints are underutilized (e.g., extension_type accepts a free string despite 13 known values); (5) no idempotency hints despite these being state-modifying operations. Tool names follow verb_noun convention well (add_*). The descriptions answer WHAT the tool does but rarely WHEN to use it or what prerequisites exist. This is typical of domain-specialist toolkits, functional but not optimized for agentic reasoning.
Tools (7)
add_app_extensionwritesource verified75/100
Add an App Extension target to the project and embed it in a host app. Supports Widget, Push Notification, Share, and other extension types.
add_build_phasewritesource verified66/100
Add custom build phases
add_dependencywritesource verified69/100
Add dependency between targets
add_filewritesource verified72/100
Add a file to an Xcode project
add_frameworkwritesource verified71/100
Add framework dependencies
add_swift_packagewritesource verified76/100
Add a Swift Package dependency to an Xcode project
add_synchronized_folderwritesource verified68/100
Add a synchronized folder reference to an Xcode project
No output schemas documented for any tool. LLMs cannot predict return structure or plan downstream tool calls. Pattern:tool-chain and pattern:response-shaper require output documentation.
Enum parameters declared as free strings. extension_type, phase_type should be formal enums (not open strings) to prevent hallucinated values and guide LLM selection.
No error handling guidance in any description. LLMs cannot recover from failures ('target not found', 'file already exists', 'circular dependency'). Pattern:recovery-guide and pattern:error-classification not applied.
Add formal output schemas for each tool. Example for add_app_extension: {type: object, properties: {target_id: {type: string}, extension_target_id: {type: string}, embed_phase_id: {type: string}, status: {type: string}}, required: [target_id, extension_target_id]}. This enables LLM planning and chaining.
Convert enum-like parameters to formal enum constraints. Change extension_type from string to enum with values ['widget', 'notification_service', 'notification_content', 'share', 'today', 'action', 'file_provider', 'intents', 'intents_ui', 'keyboard', 'photo_editing', 'document_provider', 'custom']. Repeat for phase_type: ['run_script', 'copy_files'].
Add error recovery guidance to each description. Template: '[description]. If the target does not exist, call get_targets() first. If the file is already in the project, calling again is idempotent and returns the existing reference.' Example for add_file: 'Adds a file to an Xcode project. If the file is already present, this operation is safe to retry and returns success. If the project does not exist, the call fails with a clear error message.'
Document conditional parameter requirements explicitly. For add_build_phase: 'If phase_type is run_script, the script parameter is required. If phase_type is copy_files, destination and files are required.'
Normalize file path semantics in add_file and add_synchronized_folder. Choose one: always absolute, or always relative to project root. Document clearly and consider adding a base_path parameter for clarity.
No idempotency hints on state-modifying operations. LLMs do not know whether retrying a failed add_file is safe or risks duplicates. Pattern:idempotent-operation not applied.
Ambiguous parameter semantics in add_file and add_synchronized_folder. 'file_path' and 'folder_path' descriptions state 'absolute, or relative to the base directory the server was started with, not to the directory containing the .xcodeproj'. This is confusing and error-prone. Should clarify or normalize to single approach.
Several parameter descriptions are under 50 characters and lack actionable context. Examples: 'Add dependency between targets' (40 chars), 'Add custom build phases' (40 chars). Baseline for A+ tools is 72 chars avg per param.
No distinction between required vs. optional parameters in descriptions. Example: add_build_phase has 'script' (required for run_script) and 'destination' (required for copy_files), but descriptions don't state conditional requirements. Pattern:tool-description does not address this.
add_build_phase
Add tool annotations (destructiveHint for applicable tools). All 7 tools modify the Xcode project, declare them all with destructiveHint=true in the tool definition. This signals to agents that retry logic must be idempotent or confirm-before-execute.
Expand descriptions for low-char-count tools. Minimum 50 chars. Examples: add_dependency -> 'Adds a build dependency from one target to another. The dependent target will be linked with the dependency target's output.'
Add WHEN-to-use context to ambiguous tools. Example add_app_extension: 'Use this to add iOS App Extensions (Widgets, Push Notification handlers, Share extensions, etc.) and embed them in a host app. Call this after create_target if you need to set up an extension from scratch.'
Document parameter order/dependency. If some params are only meaningful in certain combinations (e.g., embed=true only for custom frameworks), state this in both param descriptions.
Return success indicators in responses. At minimum, include the new/modified target ID, build phase ID, or file reference so agents can reference the change in subsequent calls.