Released Seiro MCP v0.1.0, Including Skills Support

On February 18, 2026, Seiro MCP finally reached version 0.1.0. At first I had so little confidence that I started from 0.0.1. The major topics this time are Skills support and added diagnostic functionality around SDKs. I am a heavy user of Seiro MCP to the point that I use it every day, so I decided that if I am using it this much myself, it is fair to call it 0.1.0. Incidentally, I also added a logo.
New Feature 1: Skills Support
Happily, I added Skills support as a major feature. Even though Skills have been added, the conventional flow of directly calling MCP remains as it was. So why did I create Skills? Because I thought they could be used to properly tell Codex the order of using the tools provided by MCP and their detailed information.
The current tools do not have a hard rule, but the expected flow is roughly the following call order.
1. validate_sandbox_policy 2. build_visionos_app 3. fetch_build_output
So I also wrote that in SKILL.md. Skills are currently expected to be used explicitly, and once they stabilize, I plan to make them usable automatically as well.
While adding Skills support this time, I also read the following specifications and feel like I became a little more familiar with them.
New Feature 2: Expanded Diagnostics When Problems Occur in validate_sandbox_policy
validate_sandbox_policy is the tool used first to check whether this MCP server can be used. But when a problem occurred there, it was difficult to isolate the cause. I now return metadata for troubleshooting.
The metadata details.diagnostics is evidence data showing under what conditions the validate_sandbox_policy tool made SDK determinations. You can check the detection path with probe_mode, the actual required conditions with effective_required_sdks, and the actual detection results with detected_sdks_*, so I tried to make it possible to isolate sdk_missing cases at low cost.
There is also a new tool.
New Feature 3: Added the inspect_xcode_sdks Tool
inspect_xcode_sdks is provided as a read-only tool. It is used before builds and similar operations to check the local SDK state, and using it when validate_sandbox_policy has a problem helps solve the issue. These processes involve access that would normally become a security sandbox error in ordinary Codex, and the intention is to allow limited access through an MCP tool.
Personally, I think it is better to restrict AI's access to the environment as much as possible, and I think these MCP tools have value because they help avoid simply granting full access.
In the AI era, I think there is a pattern of exploring things that, until now, I would not have done properly because the coding cost was too high, through the process of building the tools I need myself. Of course, the goal is to build and use them, but another goal is to accelerate learning through the process and give myself good feedback.