Released Seiro MCP v0.2.2, So Missing Schemes Are No Longer a Worry
This is really just a small update, but I added a tool called inspect_xcode_schemes. It improves cases where relying on Codex to specify a scheme nicely would sometimes result in errors because the scheme could not be found.
The release itself is below.
When a scheme cannot be found, having Codex check through this tool makes it possible to execute the build more reliably.
At the same time, I also added a new key to config.toml. The key is [visionos].default_project_path, and it specifies the project path. If it is not specified, the current directory becomes the path. But for example, there may be an Xcode project one level down, and in that case specifying it here lets it become the build target.
It looks like this.
config.toml
...
[visionos]
allowed_paths = []
allowed_schemes = []
default_project_path = "/path/to/your/project.xcodeproj"
default_destination = "platform=visionOS Simulator,name=Apple Vision Pro"
required_sdks = ["visionOS", "visionOS Simulator"]
xcode_path = "/Applications/Xcode.app/Contents/Developer"
xcodebuild_path = "/usr/bin/xcodebuild"
max_build_minutes = 20
artifact_ttl_secs = 600
cleanup_schedule_secs = 60
...Small Note
Xcode also gained MCP server functionality and AI integration in the recently released 26.3. If you use Xcode as your main environment, I do think it makes sense to use AI inside the official IDE. But when using it as an MCP server, I wondered whether Seiro MCP might still have some advantages, so I asked Codex. (There is probably some flattery from Codex.)
By the way, when using Xcode MCP, naturally, the relevant project needs to be open in the IDE. I also verified it, and that does seem to be the case.
With Seiro MCP, there is no need to open the project or launch Xcode, so it may still have an advantage in this area.
Notes
Thinking about it carefully, I have started to feel that the name config.toml is too likely to conflict and should be changed. So I plan to modify it to use seiro-mcp.toml instead. This is how more and more improvement points keep coming to mind. That said, I did not start out intending to use config.toml from the beginning. Originally, the assumption was that the configuration would be written in Codex's configuration file, which led to this name. Later, for convenience, I made it possible to place it directly under the project root. I should have changed it at that point, but it is true that I did not think that far.
For a while, I plan to make both filenames usable.