# Quickstart

Two things have to happen before an agent can sign in as you: a **passkey has to be enrolled**,
and an **agent has to be connected**. They are independent, and enrolment is the one that needs
you.

## 1. Connect an agent

Agent Passkey is a remote MCP server that speaks OAuth 2.1. There is no API key to copy, because
there is nothing to key — authority lives in a grant you can read and revoke.

```bash
claude mcp add --transport http agent-passkey https://app.solospace.dev/mcp
```

For Claude.ai and Claude Desktop: **Settings → Connectors → Add custom connector**, and paste
`https://app.solospace.dev/mcp`. Everything else is discovered. For Cursor:

```json
{ "mcpServers": { "agent-passkey": { "url": "https://app.solospace.dev/mcp" } } }
```

The client registers itself, opens a browser, and you land on one consent screen. On it you
choose:

- **which accounts** the agent may sign in to — each one is a separate tick, and the ones you
  leave unticked are invisible to that agent forever;
- **which scopes** — `connectors:read` (see the catalogue), `signin` (produce a signature),
  `approvals:read` (see its own pending approvals);
- **how long** the authorization lasts.

Hold Allow. The agent is connected.

A grant can only ever narrow. Nothing an agent does can widen it, and revoking it on the dashboard
takes effect on that agent's very next request — there is no cache in between.

## 2. Enrol a passkey

This is the part no agent can do, and that is the point. A passkey is created in **your** browser,
on a site **you** are already signed in to, using the Agent Passkey extension.

1. Install the extension and point it at your account.
2. Sign in to the site yourself, as you normally would.
3. Go to that site's security settings and add a passkey. The extension answers the registration
   ceremony: the key is generated inside the service, and the site registers its public half.
4. The connector appears on your dashboard.

Because you were already signed in when the key was created, there is no first login to automate,
and no replayable secret anywhere in the system. An agent driving a browser is served
`navigator.credentials.get` only — `create` is deliberately not served on the agent path, so an
agent cannot quietly register new credentials.

## 3. Write the operating notes

The single highest-value field on a connector is **`notes`**: a sentence or two of prose saying
how that site's passkey flow actually behaves.

> Google offers the passkey on the account-chooser or after the email step. If it asks for a
> password first, click "Try another way".

That is a real note, and it is the difference between a sign-in that works and an agent staring at
a password field. Write them as **prose, never CSS selectors** — a recorded selector is wrong the
day the site redesigns, while "click Sign in with a passkey" stays true for years.

Notes are returned first in every `passkey_list` result, and are folded into `passkey_howto`.
Well-known sites ship with a default note; a note you write on the connector always wins, and is
marked `notesSource: "connector"` so the agent knows to trust it over the default.

## 4. Choose the mode

Per connector, on the dashboard:

- **approval** — a human is asked, on their phone, before every signature. `UP=1/UV=1` is set only
  after that tap, because only then is it true. Budget up to 90 seconds per sign-in.
- **silent** — signs `UP=0/UV=0`, truthfully. No human is woken. Most relying parties reject
  assertions with those flags clear, so this is useful for testing and for the few sites that
  accept it, not as a way to make approval-gated sign-ins unattended.

## 5. Tell the agent to sign in

```
Sign me in to google.com.
```

A well-behaved client calls `passkey_howto` once, then `passkey_list`, then drives the page. If
your agent has no browser tools at all, it can still list connectors and sign bytes — but it
cannot complete a sign-in, and it should say so rather than guess.
