Connectors
Hosted MCP servers added by URL — sign-in with MCP authorization, the Popular connectors, approval before tools that change things, accounts with auth "mcp", and why your app should use a connector instead of reimplementing an API.
A connector is a hosted MCP server — Canva's, Notion's, Linear's — added to Chataway by its URL. The user signs in with their own account in the browser, and the service's tools reach the agent in every project where the connector is on. No code runs on the Mac, there's nothing to review, and nobody pastes a key.
For you as a developer, connectors matter in two ways: if your service has an MCP server, users can add it as a connector today; and if you build an app around a service that has one, your app should use the connector rather than reimplement its API.
#Adding a connector
Apps → Store → Add a connector, then paste the server's URL (or pick one of the Popular connectors). The Install from GitHub box takes an MCP URL too.
https://mcp.canva.com/mcp- Chataway contacts the server. If it wants a sign-in, the screen shows Not connected · Connect Canva.
- Connect opens the service's own sign-in page in the browser. The user signs in and allows Chataway.
- Back in Chataway, the screen shows Connected (with the account name when the service provides one) and lists the server's tools, each marked reads, changes things or can delete (from the server's tool annotations).
- Add Canva — enabled only once the sign-in worked.
The connector is labelled Connector · by canva.com: its tools run on that service, and what the agent passes to them is sent there under the user's account.
Popular connectors lists servers whose sign-in has been verified end to end: Canva, Notion, Linear, Sentry and Stripe. Any other https MCP URL works the same way if the server supports the sign-in described below.
#Approval before changes
Every connector gets a setting, Ask before actions that change things, on by default. While it's on, each call to a tool the server doesn't mark readOnlyHint: true shows a card first:
Canva: Update design?
This can change or delete things in your Canva account.
title: "Q3 poster" [ Allow ] [ Cancel ]Tools marked read-only never ask. Cancel means nothing is sent, and the agent is told so. Users can switch the setting off on the connector's page.
#How it behaves
- Every agent. Connector tools reach Chataway's own chat, Claude Code, Codex, Cursor and Grok through Chataway (OpenCode doesn't get app tools yet).
- Signed out? If the login expires and refreshing it fails, the tools stay listed; the first call shows a Connect card in the chat and continues once the user is back in.
- The tool list is the one from when it was added. Tools the server adds later appear after the connector is removed and added again.
- Removing a connector forgets its login and Chataway's registration with the server.
#Use the connector, don't reimplement the API
If you're building an app for a service that already has a connector, don't wrap its REST API yourself — you'd be asking users for a key or another OAuth app, and duplicating tools they may already have. Declare the connector as a dependency and let the agent combine its tools with yours:
"requires": {
"connectors": [{ "url": "https://mcp.canva.com/mcp", "reason": "Fast, reliable Canva edits" }],
"apps": [{ "id": "browser-use", "reason": "Opens canva.com when the connector isn't connected" }]
}The install sheet then offers Connect inline (the same sign-in as above) or Skip. A connector is a fallback unless you mark it "required": true, so write your tools and instructions for both cases: "Use the Canva tools; if they aren't available, say so and use the browser." Build an app only for what the connector can't do — a panel, cards, files from the Mac, combining several services.
#Offer your service as a connector
Users can add your MCP server as a connector without any Chataway manifest, if it implements the MCP authorization spec:
| Your server | Why |
|---|---|
Streamable HTTP over https | The transport Chataway speaks. |
An unauthenticated request gets 401 with WWW-Authenticate: Bearer resource_metadata="…" | How Chataway learns a sign-in is needed, and where to look. |
| Protected Resource Metadata (RFC 9728) naming your authorization server | Discovery. Its resource must match the endpoint. |
Authorization Server Metadata (RFC 8414) with a registration_endpoint | Chataway registers itself (Dynamic Client Registration, RFC 7591) as a public client: token_endpoint_auth_method: "none", redirect https://chataway.co/apps/oauth/callback. |
PKCE S256 and the resource parameter (RFC 8707) | Required on authorize, token and refresh. |
Tool annotations: readOnlyHint, destructiveHint, title | Drive the reads / changes / can-delete labels and the approval card. Mark read-only tools honestly — they're the ones that run without asking. |
Servers that only register approved clients with a secret, or have no registration endpoint, can't be added as connectors; the screen says why.
Want a store listing too — your own icon, a panel, file hand-off, cards? Ship a cloud app whose remote.mcpUrl is that server and declare its account with auth: "mcp":
"accounts": [{ "id": "acme", "label": "Acme", "auth": "mcp", "scopes": [], "required": true }]No authorizeUrl, tokenUrl or clientId needed — see Connected accounts.