That sounds like a perfect use case for extensible build tools in the long run.
For the moment though (last I checked anyway) including an executable target interferes with iOS compatibility package‐wide.
The most vanilla solution in the meantime would be to provide a build phase for users to copy and paste. The short script would clone, build, and execute your package as a separate entity (caching it of course). The .swiftpm directory would be a good place to store the cache. This Gist demonstrates a more complete, permanent, system‐wide install of an arbitrary package tool; you could use it as a starting point, but strip out the parts you don’t need.
But for users already familiar with the package manager, all you really have to do is make it obvious that you vend the tool as a Swift package. They will then be able to figure out countless ways of integrating it into their workflow just the way they want. They may use the package manager directly, or they may use some third party tool that further simplifies the process in some way (there are many such tools and scripts out in the wild).