One address, every client
Connect Wend to your agent
Wend speaks MCP, so the assistant you already use can ask about the people you know, propose what it learns, and draft on your behalf. Six clients, six real flows. Each one below is the exact sequence, and the single detail that decides whether it took.
The server
https://www.trywend.io/api/mcpStreamable HTTP, OAuth 2.1 with PKCE and dynamic client registration. Sign-in happens inside your own client, so there is no key to paste. The single exception is the Claude Desktop extension, which runs a small bridge on your machine and asks for a key itself.
Always the www host. The bare domain redirects, that redirect is cross-origin, and several clients drop the sign-in header when they follow it. What you see then is a server that looks broken rather than a URL that was one label short.
Claude Desktop
Desktop app, and claude.ai with it
Two ways in, and they end in different places. The extension runs a bridge on your Mac and holds a key in the keychain. The connector is account state, so one setup covers claude.ai, the desktop app and mobile at once.
- Mint a key at your account settings. You paste it once, into Claude, and never into a chat.
- Download the extension and open it. Claude installs it in a click.
- Claude asks for the key on first run and stores it in your operating system keychain, not in a file.
- Start a new chat. A chat already open never gains new tools.
Or add it as a custom connector instead, which needs no key at all: open the prefilled dialog in Claude, check the name and the address, click Add, then Connect and sign in. On a Team or Enterprise account an owner does this from admin settings first, and everyone else clicks Connect.
The one that bites: Do not hand-edit claude_desktop_config.json for this. That file's server map is the local stdio one, and a remote entry there is parsed and silently ignored. The extension and the connector are the two paths that work.
Claude Code
Terminal
- Run the command. It registers the server and writes nothing else.
- Run /mcp inside Claude Code, pick wend, and finish the sign-in that opens in your browser. From the shell, claude mcp login wend does the same.
claude mcp add --transport http --scope user wend https://www.trywend.io/api/mcpThe one that bites: --scope user is what makes Wend available in every project. Drop it and the server belongs to the directory you happened to be standing in, which reads later as an install that did not take. Already added Wend on claude.ai? Claude Code picks up claude.ai connectors on its own, but only while your active login is a Claude subscription rather than an API key.
Cursor
Editor
- Click the link. Cursor launches if it is closed and shows an install confirmation.
- Approve it. Cursor writes the wend entry into ~/.cursor/mcp.json.
- Open the MCP list on Cursor's Customize page and connect. Sign-in opens in your browser.
Or paste it yourself, into ~/.cursor/mcp.json
{
"mcpServers": {
"wend": {
"type": "http",
"url": "https://www.trywend.io/api/mcp"
}
}
}The one that bites: Keep "type": "http". With no transport named, Cursor infers stdio and tries to run the address as a shell command, which fails in a way that says nothing about transports.
VS Code
GitHub Copilot, agent mode
- Click the link. VS Code opens and asks you to confirm the server.
- Confirm. The entry lands in your user MCP configuration, reachable again from the MCP: Open User Configuration command.
- Open Copilot in agent mode and sign in when VS Code prompts.
Or from a terminal, if your browser will not fire a scheme
code --add-mcp '{"name":"wend","type":"http","url":"https://www.trywend.io/api/mcp"}'Or paste it into .vscode/mcp.json, for this workspace only
{
"servers": {
"wend": {
"type": "http",
"url": "https://www.trywend.io/api/mcp"
}
}
}The one that bites: The key is servers, not mcpServers. VS Code is the one client here that names the map differently, and the wrong key parses cleanly and loads nothing.
Codex CLI
Terminal
- Run the command. Codex registers the server in its own config.
- Add the RMCP flag at the top of ~/.codex/config.toml, if it is not there already.
- Start Codex and finish the sign-in it opens.
codex mcp add wend --url https://www.trywend.io/api/mcpOr write the whole block by hand
experimental_use_rmcp_client = true
[mcp_servers.wend]
url = "https://www.trywend.io/api/mcp"The one that bites: The flag is half the install. Codex reaches a remote server through its RMCP client, which is off by default, and without the flag it reads url as an unknown key. Wend never appears, and there is no error to read. The flag is top level, above every table, or TOML files it under the last section it saw.
Gemini CLI
Terminal
- Run the command, or write the settings block below.
- Start Gemini. The first use opens your browser to sign in with Wend.
gemini mcp add --scope user --transport http wend https://www.trywend.io/api/mcpOr paste it into ~/.gemini/settings.json
{
"mcpServers": {
"wend": {
"httpUrl": "https://www.trywend.io/api/mcp",
"oauth": {
"enabled": true
}
}
}
}The one that bites: httpUrl, not url. Gemini reads url as an SSE endpoint and Wend serves streamable HTTP, so the wrong key gets you a client connected to nothing that reports no error.
Anything else
Any MCP client that speaks HTTP
Most file-configured clients take this shape. If yours asks for a transport by name, it is streamable HTTP, never SSE. Clients that speak OAuth pick up the sign-in from the server itself.
{
"mcpServers": {
"wend": {
"type": "http",
"url": "https://www.trywend.io/api/mcp"
}
}
}Zed, Cline, Windsurf, Goose, LM Studio, Open WebUI, LibreChat and OpenClaw each have one quirk worth knowing, and every one of them takes the same address and the same scopes as the six above.
What it can do, once it is in
14 named tools, each annotated and each behind one of four permissions, plus 3 older meta-tools (search, fetch, execute) kept for clients built against the earlier surface. Your client's tool list shows only what your grant allows, and the server checks the permission on every call rather than trusting the list.
Read
wend.read
Ask about your network. Nothing changes.
wend_search_graph · wend_get_person · wend_list_due · wend_who_do_i_know_at
Propose
wend.propose
Put something in, as a proposal you confirm in Wend.
wend_propose_fact · wend_propose_person · wend_capture_note
Draft
wend.act.draft
Write the words, and pull queued work. Nothing leaves.
wend_draft_message · wend_draft_intro · wend_pull_tasks · wend_complete_task
Send
wend.act.send
Ask for a send, and confirm one. The scope that reaches another person.
wend_act · wend_confirm_action · wend_cancel_action
Draft and send are separate on purpose. An agent that should write into a review queue and never reach another person gets exactly that, and it is the server that refuses, not the client that hides a button.
Nothing goes out on one call
Sending is two tools, not one. wend_act writes the message and returns the exact outgoing words with a confirm token, and sends nothing. You read those words. wend_confirm_action is what sends them, and wend_cancel_action drops the whole thing.
It is two tools rather than a dialog because claude.ai has no MCP elicitation, so a server cannot raise a confirmation of its own there. A preview that arrives as a tool result is one every client can show. The cost is one extra round trip; the thing it buys is that the words you approved are the words that went.
When Wendy writes, she writes as herself, on your behalf, and signs her own name. She never sends as you. On iMessage she does not send at all: she drafts, sends you a link, and you read the exact words, edit them if you want, and send from your own Messages with one tap.
Next
- Wend from the command line: working out of a terminal, and running Wend on the subscription you already pay for.
- Wend for Mac: where the memory itself lives. It reads what your machine already holds and answers your agent from there.