STOREWRENCH
A safer bridge between Shopify and the AI tools you actually want to use.
StoreWrench is a Shopify app and MCP server in active development, built to give AI assistants focused, auditable ways to understand and work with a store instead of handing them raw admin access and hoping nothing interesting happens.
It is early, but it is not a mockup. The embedded app already handles a real publishing workflow: create unpublished article drafts, update existing drafts, and read the result back to verify what actually changed. The local MCP can read Shopify blogs and articles through focused tools. The next job is not “add every possible action.” It is making the trust boundary solid enough that broader access deserves to exist.
CURRENT BUILD & DIRECTION
Useful already. Not trusted with the whole store yet. That is the point.
StoreWrench started with a practical problem: give an AI tool a useful way to work with Shopify without making the permission model somebody else’s problem. The fastest way to make that unsafe would be to confuse a working prototype with a finished trust model, so the roadmap is deliberately moving from narrow, verifiable capabilities toward broader access instead of the other way around.
Working now
The embedded Shopify app can create unpublished article drafts and update existing drafts, including the body, excerpt, tags, handle, author, SEO title and description, featured image, and alt text. Create stays unpublished and is verified afterward. Updates read the current state first and read it back again when the change is done.
The local MCP has focused read-only tools for listing and finding blogs, listing and finding articles, and reading a specific article. The tools are semantic on purpose: StoreWrench resolves Shopify identifiers on the server and fails closed when a request is ambiguous instead of letting the model guess.
The next trust boundary
The next major milestone is authenticated remote MCP transport with authoritative tenant binding. In plain English: a remote AI client needs a trustworthy way to prove which merchant it represents, and StoreWrench needs to decide the store and capabilities from that identity rather than accepting them from the model.
That work also includes separating credentials cleanly and giving merchants visible control over capability policy. MCP writes stay disabled while that foundation is being built. There is no useful prize for being first to discover that “the AI had permission” was not the same thing as “the AI should have been allowed to do that.”
Then expand carefully
Once the boundary is dependable, the roadmap opens into pages, richer editorial and media workflows, navigation, read-only theme inspection followed by controlled theme changes, commerce tools, audits, multi-store administration, and other merchant-facing capabilities.
A StoreWrench Assistant is planned later as an easier interface for merchants who do not live in MCP clients. Commercial readiness comes after the underlying permissions, controls, and operating model are worth selling—not before.
The order matters. Add capability, make it observable, put a useful boundary around it, then earn the right to add the next one. That is slower than wiring every Shopify mutation into a chatbot on day one. It is also a much nicer way to sleep.
CUSTOM APP DEVELOPMENT
StoreWrench exists because sometimes the missing piece really does need to be built.
The sensible first question is still whether a mature app, native feature, or automation already solves the problem. If it does, use it. If your workflow keeps paying a tax because the off-the-shelf answer almost fits, Raymond Tec builds focused tools, plugins, dashboards, portals, and integrations around the part that does not.
That same approach is shaping StoreWrench: narrow capabilities, visible permissions, read-before-write behavior, failures that stop safely, and as little custom machinery as the problem actually needs. The goal is useful software you can operate after the clever part is over.