Today, Sunday, May 31, I am publishing the first version of Swipium, a free and open-source project I have been working on over the last few months.
The adoption of AI tools and agents in development teams is becoming increasingly common, and delivery speed increased significantly over the last year. But along with that speed, more software errors also appear.
The interesting thing is that many of those errors are not complex. They are usually the result of deploying code without enough testing, or with unit testing around isolated functions, but not around the software as a whole within a staging or preproduction environment.
That, without judging, is fairly normal in small teams that do not have a dedicated QA or an automated test suite. Many times, the workflow ends up being: make a TestFlight version, test manually for a bit, and see what happens in production.
That is where Swipium comes in.
For product context, the Swipium homepage explains the core MCP workflow, and the current public v1 scope defines what is supported in this first release.
The purpose of Swipium MCP, and of this 1.0.0 version, is to help developers ensure an acceptable level of quality over their work and product before doing any deploy or build. The idea is to reduce errors in testing or production phases, and improve the quality of the final product.
Swipium gives developers who use agents a suite of tools so the agent can run real tests in the context of E2E flows on a real simulator, and not only against the code.
If you want to connect it locally, the quick start documentation covers installation and MCP setup, while the integrations page covers Claude Code, Gemini, Codex, Grok, and Grok Build.
The MCP provides testing flows, mapping, error and fix tracking, test case creation with steps, preconditions, and expected results, plus reports that grow as it gains more knowledge about the business and its goals.
Today I am launching version 1.0.0, but I expect to keep extending the MCP toward the creation of E2E automation suites on simulators and, eventually, on real devices. I would also like to add security testing, performance testing, UX improvement proposals, and active follow-up through future integrations.
I am taking the project seriously because I enjoy building this kind of thing, although I am doing it as a hobby. I have several ideas I want to implement, not only to grow the MCP, but also to learn along the way.
I have several years of experience in the software industry and also in testing, but publishing version 1.0.0 taught me a lot about building an MCP: how an agent works, how to connect it, its limitations, its happy paths, and many other things.
What interests me most is making this an open-source project that anyone can use, and that can help reduce time and improve output.
We will see how many versions this lasts. I hope several, because building it has been very entertaining. But yes, it takes time.