# A URL and a browser sign-in

Bird's MCP server is hosted, so any client that speaks MCP reaches it with one URL and one sign-in. There is nothing to install and no local process to keep running.

## One URL, one sign-in, no install

Every client names this screen something different, so what follows is the shape rather than a menu path. If yours takes a remote server URL, this is all it needs.

**the client's MCP config**

```json
{
  "mcpServers": {
    "bird": { "url": "https://mcp.bird.com" }
  }
}
```

**the client's server list**

bird → Needs login

- Before: not signed in
- After: ready

The control is called Connect, Authorize or Needs login depending on the client. Approve the consent screen and the row reads ready.

**in the chat**

```bash
> who am I acting as on Bird?

  workspace ws_7Qk   region eu1

# tools listed but every call 401s means the sign-in
# above never completed
```

## What the tools cover. The same three operations every Bird client gets. A chat client has no shell, so it calls the tools directly rather than driving the CLI.

- Send a message. Send it, then read it back, because accepted is not the same as arrived.
- Set up a sender. Create the domain, add the DNS records it hands you, then verify. Not immediately: DNS takes its time.
- Get notified of events. Tell Bird where to send them, then test that they land. Keep the signing secret from the create call, because it is never shown again.

### What to ask for

- Which workspace and region am I acting as right now?
- Send me a test email and tell me when it lands.
- What bounced in the last hour? Group it by reason.
- Is this number reachable before I send? Tell me the carrier.
- Is mail.acme.dev verified, and which DNS records are still missing?