Released Seiro MCP, an MCP for Accelerating Development for visionOS
I usually use Codex CLI as my main AI agent, but at least in my environment, autonomous coding for Swift-based visionOS development did not go well. I decided to take the plunge and create Seiro MCP.
There are many things I want to write about, from the background to the structure and usage, so I will try making this a short series for a while. The repository is here.
Background
The outline is roughly what I wrote above, but I will describe it in a little more detail.
For me, Swift is the first language I learned after the ChatGPT boom, so I was learning and coding with AI from the beginning. Other languages were ones I had learned before the ChatGPT boom, so I treat them somewhat differently in my mind.
I learned Swift to build visionOS apps, but AI-agent-based coding with Swift did not seem to go well. At first, I copied code generated by ChatGPT into Xcode and ran it, but it often became an error. In those cases I fixed it myself, or told ChatGPT about the error and had it fix it, and continued that cycle.
After Codex CLI, I did similar things through the terminal, but because AI could access the code directly, fixing errors became easier. However, there were still quite a few times when Codex said "done" and produced code that errored in Xcode.
So I started having Codex CLI build directly, find errors, and fix them. However, on the powerful security sandbox that is one of Codex CLI's advantages, building with the xcodebuild command becomes a sandbox violation, so that approach could not be achieved. The xcodebuild command inevitably needs directory access outside the repository, which causes an error. Of course, I could remove those constraints, but personally I wanted to keep everything completed inside the security sandbox.
For Xcode builds, there is an MCP tool called cameroncooke/XcodeBuildMCP. I tried introducing and using it in my own environment, but for some reason it did not work well. I could have decided to spend more time investigating, but the unclear part seemed to be happening between the AI agent and the MCP server, and grasping the situation looked difficult, so I became exhausted.
Incidentally, alongside learning visionOS, I was also learning server-side Swift to get used to Swift, and on that side autonomous coding worked fairly well. My personal impression is that autonomous coding by AI agents depends quite a lot on compatibility at the language ecosystem level, more than differences in functionality between AI agents.
It Has Become Easier to Build the Tools You Use Yourself
Until now, even if a tool did not fit your environment perfectly, I think the mainstream approach was to make various adjustments and use it anyway, in other words, to adapt yourself to the system. Of course, if it can be solved by changing configuration items, that is fine.
In the current era, generative AI has developed, and anyone can make small things. At the same time, for people who can already code, I think it has become a world where custom tools can be built faster.
"Let's try making a visionOS build MCP server that works in my own environment."
That was the initial motivation. If only this part worked, I thought I could run an autonomous coding cycle: coding by AI, error detection by the MCP server, and correction by AI.
For now, within my own range, the language where autonomous coding by AI agents works best is Rust. Precisely because compile-time checks are so strict, it is easy and manageable for AI to do trial and error.
That led to the development of Seiro MCP this time.
There Are Many Things You Learn Once You Start Building
There are various MCP servers I used for a while but no longer use.
GitHub's MCP server is a good example. It was useful for creating pull requests and similar tasks. But I do not use it now, and I am not sure whether it is an issue with instructions to the AI agent, but sometimes it creates content for me to paste so I can make the PR myself, or it uses the gh command instead of MCP.
So I wrote in AGENTS.md that pull requests should use the gh command, and after that it always used that, resulting in MCP no longer being used. I still do not fully understand when MCP is used, but even with Seiro MCP there are cases where it is not used. In this area, probably just preparing an MCP server alone is not enough; a mechanism to install prompts, like SpecKit, is also necessary.
There are many other things you learn by building something. By building it, it became easier to demo in front of people, and I became able to receive opinions. I demoed it during a social gathering at visionOS TC and received various feedback. For example, I was told that automating only through build and error feedback is not enough, and that loops of fixes caused by strange rewrites can also happen easily. There were also comments about cases where coding is complete and there are no errors, but mistakes in coordinate systems occur.
To solve these problems, simply being a build server is probably not enough. I think it is necessary to create an environment that combines prompts and tools as a set. Rather than specializing Seiro MCP in builds and releases, I plan to specialize it as a convenient environment for accelerating development for spatial computing.
This entry ends at a preliminary stage, but next time I plan to write about the tool itself.