TZ-C
Toolzilla Cloud
Point your client at one URL and start granting tools in minutes. We run the gateway, the vault and the memory layer.
MCP control plane // for high-risk industries
Summon any toolTools you won’t find elsewhere
One MCP endpoint for every tool your business runs, from ad servers and trackers to payments and content. Per-agent access control, a credential vault and shared memory, built into the gateway.
Drop-in for
- Claude
- Codex
- Any MCP client
- EXT-VISION
- Kazza
- Slack
- Notion
- Ad servers
- Traffic trackers
- Affiliate programs
- Payment processors
- Content systems
00 // your mcp.json
Five servers in. One endpoint out.
Every tool you connect today is another process, another secret on disk, and another thing no policy covers. Replace the whole list with one line.
{"mcpServers": {"kazza": { env: KAZZA_API_KEY }"ad-server": { env: ADSERVER_TOKEN }"tracker": { env: TRACKER_API_KEY }"payments": { env: PAYMENTS_SECRET }"cms": { env: CMS_TOKEN }}}5 servers · 5 secrets on disk · no access control
{"mcpServers": {"toolzilla": { url: "https://mcp.toolzilla.com" }}}1 endpoint · 0 secrets on disk · deny by default
With Toolzilla, four fewer servers and five fewer secrets on disk.
Pipeline // how it works
Three steps. Then it runs.
Toolzilla sits between your agents and the tools your business already runs. Set it up once and every call is routed, checked and credentialed.
- 01
Plug in
Every tool, one endpoint
Point Claude, Codex or any MCP client at Toolzilla once. Your ad servers, trackers, payment processors and content systems all sit behind it.
- 02
Set rules
Who touches what
Give each agent a role, down to the scope. A support agent can issue a refund and never a payout. Anything you did not grant is denied.
- 03
Let it run
Keys locked, work moving
Credentials stay in the vault and are injected at call time, and every agent shares one memory of what has already been done.
Step 02 // set rules
Roles get tools. Agents get roles.
Grant access to a role, down to the scope, and assign agents to roles. Nothing is ever granted to a credential, and everything not on the list is refused.
- Tool and scope level grants
- Deny by default, explicit allowlists
- Nobody moves money unless you say so
Policy bench
agent release-agent → role release
| Tool | Scope | Decision |
|---|---|---|
| kazza | reports:read | Granted |
| ad-server | campaigns:pause | Granted |
| ad-server | budgets:write | Denied |
| tracker | conversions:read | Denied |
| payments | refunds:create | Denied |
| payments | payouts:send | Denied |
| cms | scenes:publish | Granted |
3 of 7 scopes granted · 4 denied by default
Step 03 // keys stay locked
Agents never hold a raw secret.
Processor keys, ad server tokens and CMS credentials live in Toolzilla and are injected after the policy check, on the way out to the tool.
A leaked agent context can't leak a credential it was never given.
- →release-agenttools/call cms.publish_scene
- policyrole=release scope=scenes:publishgranted
- vaultinject CMS_TOKEN at call timesealed
- logcredential stripped before writeclean
- ←201scene 0142 scheduled
agent context: 0 secrets
Rotate in one place
Change a processor key once. Every agent allowed to use it is on the new one by its next call.
Revoke instantly
Pull a grant and it is gone for every agent at once. No config to redeploy, no context to scrub.
Stripped from logs
Secrets are injected after policy runs and removed before anything is written down.
Deployment // cloud or self-hosted
Your cloud or ours.
The same gateway, vault and memory layer either way, with the same policies.
TZ-S
Self-hosted
Run the same control plane inside your own network, next to the servers it fronts, with your keys never leaving it.
Questions from the floor
Early access // request access
Put your agents on a leash worth having.
We are onboarding teams in batches. Tell us what you run and we will get you on the floor.