Your ZeroClaw agent can call any API: here's how to decide which calls run

You message your ZeroClaw agent on Telegram: "Send XYZ an invoice for $200."

It's a fair ask. ZeroClaw has an HTTP tool and a shell. It can find the Stripe docs, write the request and send it. The question is what happens in between. Which key does it use? Where did that key come from? What stops it sending $2,000 instead, or sending it twice? And when you check tomorrow, what record is there?

ZeroClaw is a very good place for an agent to live. Swytchcode is how that agent talks to the APIs that touch your money, your inbox and your customers. This post covers both, and how to set them up together in about ten minutes.

Why ZeroClaw

ZeroClaw is an open-source agent runtime written in Rust. Its pitch is one line: "You own the agent. You own the data. You own the machine it runs on." Here's what that gets you.

• One binary. No Node runtime, no dependency tree to keep patched. You install it, write a config.toml, and run it. It's small enough to run on a Raspberry Pi.
• Any model. Anthropic, OpenAI, Ollama and about 20 other providers, plus any OpenAI-compatible endpoint. Fallback chains keep the agent answering when one provider is down.
• Any chat app. 30+ channels, including Telegram, Discord, Matrix, email, voice, webhooks and the CLI. You talk to it where you already are.
• Supervised by default. ZeroClaw's default autonomy level asks before medium-risk actions and blocks high-risk ones. It can sandbox tools at the OS level (Landlock, Bubblewrap, Seatbelt, Docker) and signs a receipt for each tool call.
• Per-agent control. MCP servers and skills are granted to each agent through bundles. One agent can have your payments tools while another can't see them.

Those last two points matter here. ZeroClaw was built by people who assume an agent will sometimes be wrong. It gives you good controls over what the agent can run on your machine.

What it can't know is what an API call means. To ZeroClaw, a Stripe balance check and a Stripe refund are both an HTTP request. That's the gap Swytchcode fills.

Why add Swytchcode

Swytchcode is an execution layer for API calls. The agent doesn't write HTTP requests. It calls Swytchcode's MCP tools, and Swytchcode runs the call: with your credentials, against your rules, with a record of what happened.

You (Telegram, Discord, CLI)
      │
      ▼
ZeroClaw + its model
      │  swytchcode__* MCP tools
      ▼
swy mcp serve --profile operator
      │  policies, credentials, audit
      ▼
Stripe, Gmail, GitHub, ...

Here's what changes for your ZeroClaw agent.

It knows the API, not just the URL. The agent asks Swytchcode "how do I create an invoice?" and gets the exact Stripe method, its inputs and its types. No guessing from a docs page it scraped. It can search for a provider, fetch it and enable the methods it needs on its own.

Writes wait for you. Reads don't. Setup adds one baseline policy: every call that isn't a GET, HEAD or OPTIONS is held for your approval. Your balance check runs at once. The invoice waits until you tap Approve on your phone.

Approval happens outside the agent. The request goes to a separate Swytchcode bot on Telegram or Slack, not the agent's own chat. The agent can't approve its own call, and it can't talk you into it in the same thread.

Keys never go through the chat. Swytchcode stores credentials on the machine. For OAuth apps like Gmail, the agent sends you a one-time sign-in link. For API keys like Stripe's, it sends you a command to run in your terminal. If you paste a key into the chat anyway, Swytchcode won't take it, and with the lock-down below the agent has nothing else to use it with.

The agent can tighten rules, never loosen them. It can add a policy ("block refunds over $100"). It can't remove one, allow-list a call, or approve its own request. When you ask it to "turn off approvals", it replies with the command you'd run yourself.

Sandbox first. New projects start in sandbox mode, so calls go to each provider's test endpoint until you switch.

Every call is on record. swy audit shows each request, each policy decision and each approval.

ZeroClaw decides what the agent may run. Swytchcode decides which API calls go through.

The two fit cleanly because ZeroClaw already thinks in terms of grants. Swytchcode is one MCP server in one bundle, granted to the one agent you chat with.

Set it up

You need ZeroClaw installed with at least one agent, and a Swytchcode account. Approvals need the Business or Enterprise plan.

1. Install swy

Pick one. Each installs swytchcode and its short alias swy.

npm install -g swytchcode
# or, on macOS / Linux
curl -fsSL https://cli.swytchcode.com/install.sh | sh

2. Create the agent's project

swy init --operator --editor=zeroclaw --project ~/agent-swy
swy login

--operator sets the project up for an agent you chat with, not a coding agent. It starts in sandbox mode, adds the baseline approval policy, and writes the Swytchcode skill to ~/agent-swy/agent-skill/.

Swytchcode never edits ZeroClaw's config for you. ZeroClaw grants servers per agent, and that's your call. So init prints exactly what to add.

3. Add the skill to a bundle

mkdir -p ~/.zeroclaw/shared/skills/swytchcode
cp -R ~/agent-swy/agent-skill/swytchcode-operator ~/.zeroclaw/shared/skills/swytchcode/

4. Add the MCP server

Paste the block init printed at the end of ~/.zeroclaw/config.toml:

[[mcp.servers]]
name = "swytchcode"
command = "swytchcode"
args = ["mcp", "serve", "--profile", "operator", "--project", "/home/you/agent-swy"]

[mcp_bundles.swytchcode]
servers = ["swytchcode"]

[skill_bundles.swytchcode]

If you already have a [mcp_bundles.swytchcode] section, don't add a second one. TOML refuses duplicate sections and ZeroClaw won't load the file.

5. Grant it to your agent

zeroclaw agents list
zeroclaw config get agents.<agent>.mcp_bundles
zeroclaw config set agents.<agent>.mcp_bundles '["swytchcode"]'
zeroclaw config set agents.<agent>.skill_bundles '["swytchcode"]'

config set replaces the whole list. If config get printed ["web"], set '["web","swytchcode"]'.

6. Lock it down (recommended)

Swytchcode only governs calls that go through Swytchcode. If your agent can run python or node, it could edit policies.json directly. Before you connect real accounts, remove interpreters and shells from the agent's allowed_commands, and add the 11 swytchcode__swytchcode_* tools to auto_approve so ZeroClaw doesn't ask "[Y]es / [N]o / [A]lways" before every call. Swytchcode's approval already covers the calls that matter.

Then check your work:

swy doctor --agent zeroclaw --project ~/agent-swy

doctor only reads. It tells you what's missing: the grant, the skill, a forbidden path, an interpreter still allowed.

7. Connect an app and chat

Set your approval channel to Telegram or Slack at app.swytchcode.com, in a private chat with the Swytchcode bot. Then connect Stripe with a test key:

cd ~/agent-swy
swy get stripe
swy auth connect stripe

Stripe has no separate sandbox host, so the first call will ask you to set the base URL to https://api.stripe.com in manifest.json. The error names the exact entry. Most providers don't need this.

Start a chat with zeroclaw agent --agent <agent>, or message it on your usual channel:

Show my Stripe balance.

That's a read, so it runs. Now try:

Create a $200 invoice for XYZ.

The agent finds the method and makes the call. Swytchcode holds it. Your phone buzzes with the request. You approve, and the invoice goes out.

The short version

• ZeroClaw gives you a fast, self-hosted agent you can reach from any chat app, with real controls over what it runs on your machine.
• Swytchcode gives that agent a governed way to call APIs: known methods, your credentials, your rules, your approval, a full record.
• Reads run. Writes wait for you. Keys never touch the chat. The agent can add rules but never remove them.

The agent does the work. You keep the final say.

Full reference: More personal agents in the Swytchcode docs. Try it in sandbox mode first, then tell us what your agent did.