Feature Description
XcodeBuildMCP currently exposes similar capabilities through both:
- an MCP server
- a CLI with skills
In practice, this creates two execution paths that do not always behave the same way. Sometimes the MCP path is triggered, sometimes the CLI path is used, and configuration (e.g. config.yaml) does not always appear to be applied consistently.
This leads to:
- inconsistent behavior
- reduced predictability
- duplicated logic
- unclear source of truth
- higher tokens usage? (not 100% sure)
Given this, it might make sense to consolidate around the CLI as the primary execution layer and deprecate the MCP layer.
Potential benefits:
- a single execution path → more predictable behavior
- consistent configuration handling
- reduced maintenance surface
- simpler mental model for users
- lower token usage in agent workflows, since CLI interactions are typically more direct and less verbose than MCP tool calls
Use Cases
No response
Example Interactions
No response
Feature Description
XcodeBuildMCP currently exposes similar capabilities through both:
In practice, this creates two execution paths that do not always behave the same way. Sometimes the MCP path is triggered, sometimes the CLI path is used, and configuration (e.g.
config.yaml) does not always appear to be applied consistently.This leads to:
Given this, it might make sense to consolidate around the CLI as the primary execution layer and deprecate the MCP layer.
Potential benefits:
Use Cases
No response
Example Interactions
No response