Deltastring is a configuration management platform for Zendesk, with other platforms in development. The goal is straightforward: make building and maintaining your Zendesk with proper process (version control, automated testing, approval gating, sandbox-to-production promotion) easier than making changes straight in the admin centre.
The MCP is how you point your own AI assistant at all of that.
The Deltastring MCP doesn’t hand your AI assistant a translation layer in front of the Zendesk API. Your changes are staged in Deltastring first, so each one is checked against your dependencies (will this break something else that references that tag or field?) and follows the processes you’ve set. If your rule is that another team member approves any production change, the MCP honours it. The assistant can propose and apply to a sandbox; production stays a human decision.
You could generate a Zendesk API token and give it to Claude. Here is what the Deltastring MCP gives you that a raw token can’t.
Your AI understands Zendesk, and your conventions. The MCP gives your assistant Deltastring’s model of how Zendesk objects actually work, plus a best-practice and conventions layer you configure for your business: how you name your tags, how you order your triggers, and so on. Dozens of defaults ship with it, the regular Zendesk pitfalls, the timing of when automations run, trigger-order rules, the quirks that catch people out. Keep the ones that fit your business and drop the ones that don’t.
Your own context stays with the AI you already approved. Because it’s your assistant, it can draw on context you would never want to load into someone else’s AI: your branding and tone of voice, documents about how you work, whatever you keep locally. Your business has already vetted the AI tool your team uses, so this opens up quick iteration on new processes and workflows, and a fast way to find issues in existing config, without any of that context leaving your control.
Every change stays reviewable and reversible. Because the change is staged, it’s planned before it’s applied, checked against your dependencies, held for approval where you’ve asked for it, and reversible from the exact before-state. That safety envelope is the whole point, and it’s the thing a direct-to-Zendesk MCP structurally can’t give you. If you want that argument in full, see why you don’t want a direct-to-Zendesk MCP.
This grew out of real consulting work: dozens of Zendesk projects where making my own work faster and safer turned into the product. If you’d like a hand getting set up, we can put you on one of our test instances to try it against.