Wend from the command line

One command, then sign in

All three CLIs reach the same address over streamable HTTP, and all three sign in with OAuth in your browser. There is no key to paste, which matters more in a terminal than anywhere else: a key typed at a shell prompt lands in your history, and a key handed to an agent lands in a transcript.

Claude Code

claude mcp add --transport http --scope user wend https://www.trywend.io/api/mcp

Then /mcp inside Claude Code, pick wend, and finish the sign-in. --scope user is what makes it available in every project rather than the folder you were standing in.

Codex CLI

codex mcp add wend --url https://www.trywend.io/api/mcp

Codex needs the RMCP flag too, at the top of ~/.codex/config.toml. Without it Codex reads url as an unknown key, never loads the server, and prints nothing at all. The whole block, if you would rather write it by hand:

experimental_use_rmcp_client = true

[mcp_servers.wend]
url = "https://www.trywend.io/api/mcp"

Gemini CLI

gemini mcp add --scope user --transport http wend https://www.trywend.io/api/mcp

Gemini opens your browser to sign in on first use. Its own default scope is the project, so --scope user is doing real work here as well.

OpenClaw

openclaw mcp add wend --url https://www.trywend.io/api/mcp --transport streamable-http
openclaw mcp login wend

Both halves. The first registers the server, the second runs the sign-in, and a server registered without one answers 401 forever.

Editors and desktop apps have their own flows, each with its own trap. They are in connect Wend to your agent.

It runs on the subscription you already pay for

This is the part worth understanding before you set anything up. Wend supplies the memory and the tools. The model that reads them, decides what to call and writes the sentence is the one your CLI is signed in to: Claude Code reasons on your Claude subscription, Codex on your ChatGPT account, Gemini CLI on your Google one.

So Wend holds no model key of yours, meters no tokens, and puts no cap on how much you ask. There is nothing to top up here and nothing to run out of. If you are already paying for a frontier model, that spend is the budget, and Wend is the thing that finally gives it something worth reasoning over.

The same holds for work that runs while you are not there. An automation in Wend is a prompt, a cadence and a typed grant, and Wend never calls a model to run one. It queues the task; your connected agent pulls its own due work with wend_pull_tasks, runs it on its own model, and acknowledges with wend_complete_task. The scheduling is ours. The thinking is yours.

What a session looks like

You type in your own words. The agent picks the tool. These are the ones it reaches for most, and the names are the real ones, so you can check any line here against your client's own tool list.

“Who do I know at Ramp?”

wend_who_do_i_know_at

Current people and past ones, each with the fact that says so.

“Brief me on the person I am meeting at four.”

wend_get_person

Everything held about them, with the source behind every line.

“I met Sarah Chen at a dinner, she runs data at Ramp. Remember that.”

wend_propose_person

Lands in your review queue with the agent's name on it. Nothing is written until you confirm it.

“Who am I overdue to talk to?”

wend_list_due

The reach-out band, not a guilt tally.

“Draft a follow-up to the investor I met on Thursday.”

wend_draft_message

Words only. Drafting reaches nobody, and the permission to send is a separate one.

There are 14in total, each one named for what it does and annotated for your client's own confirmation prompts. Ask your agent what Wend can do and it will tell you from the server rather than from a guess.

What it will not do, whatever you type

Four permissions, granted separately: read, propose, draft, send. Your client's tool list carries only the ones your grant allows, and the server checks the permission on every call rather than trusting the list. An agent with read access alone cannot reach another person, and the refusal comes from the server.

Writes never commit. A proposal lands in your review queue carrying the agent that made it and the source it came from, and it stays there until you confirm it. That is the whole sentence Wend is built on: every fact has a source, and you approved it.

Sending is two calls. wend_act returns the exact outgoing words and a confirm token and sends nothing; wend_confirm_action is what sends them. Two calls rather than a dialog because claude.ai has no MCP elicitation, so a preview that arrives as a tool result is the one every client can show you.

And when Wendy writes, she writes as herself, on your behalf, signing her own name. She never writes as you. On iMessage she does not send at all: she drafts, sends you a link, and you read the words, change them if you want, and send from your own Messages.

The copy on your Mac

The memory itself lives on your machine. Wend for Mac reads what is already there, keeps it in one place, and serves the same tools locally over a Unix socket only your account can open, so an agent on that Mac never needs the network to answer a question about your own network.

It also knows which CLIs you have. The Agents pane looks in the fixed places each client keeps its configuration, and writes Wend into the ones it can write correctly, preserving whatever servers are already there. A client whose settings live behind a screen with no file gets the command to run instead, because a config written to a guessed schema fails silently and reads as Wend being broken.

The address is the same either way, and it does not change:

https://www.trywend.io/api/mcp