> ## Documentation Index > Fetch the complete documentation index at: https://docs.coffeechats.me/llms.txt > Use this file to discover all available pages before exploring further. # Connect an agent > What an agent needs in order to connect to Coffee Chats, which steps it can complete on its own, and where a person has to take over. This page is written for the agent rather than for the person operating it. It states the addresses, the boundary between what a program may do alone and what a person must do, and where the rest of the detail lives. The [quickstart](/mcp/quickstart.md) walks a person through the same connection at greater length, and the two pages describe the same connector. ## What an agent can do alone, and what it cannot An agent can add the connector, begin the sign-in, exchange the resulting code, and call tools. An agent cannot sign itself in. Coffee Chats accepts one kind of credential, and that credential only exists after a person has signed in and chosen what to share. There is no API key, there is no anonymous mode, and there is nothing an operator can paste into a configuration file to skip the browser. An agent that is asked to connect Coffee Chats without a person present should say so and stop, rather than searching for a key that does not exist. Plan the connection as a hand-off. The agent prepares everything, the person signs in and approves once, and the agent then works without interruption for as long as the connection lasts. ## The addresses The connector is at `https://mcp.coffeechats.me/mcp`. That address is the only value an operator has to supply. The connector names the authorization server that protects it at `https://mcp.coffeechats.me/.well-known/oauth-protected-resource/mcp`, and that authorization server publishes its own configuration at `https://mcp.coffeechats.me/oauth/mcp/.well-known/openid-configuration`. An agent host that follows the protocol reads both and finds the sign-in flow without further configuration. ## How the client identifies itself Coffee Chats does not register new clients automatically. Claude, Claude Code and ChatGPT identify themselves with a Client ID Metadata Document: the client identifier is the address of the document the client publishes, and the authorization server says it accepts these with `client_id_metadata_document_supported`. Coffee Chats accepts the addresses those three clients publish and refuses any other. A host that does not send one of those addresses has to send a pre-registered client identifier instead. The registered identifiers are `claude-ai` (Claude on the web, which also covers Claude Desktop), `claude-code`, `chatgpt`, `codex`, `cursor` and `cursor-desktop`. A host that sends none of them is refused before it reaches a sign-in page. The [quickstart](/mcp/quickstart.md) gives the setup for each host, and the [compatibility page](/mcp/compatibility.md) lists every supported application with the client identifier it uses. An agent running inside a host whose identifier is refused should tell its operator that the application is not registered rather than that the configuration is wrong. ## What the person does The person signs in with Google, or with a link Coffee Chats sends to the email address on the account, and that link has to be opened in the browser the sign-in started in. They then see a page headed "Authorize access" listing every permission the connection asked for, and they approve or deny it. The shortest clock in this flow is ten minutes, measured from the moment the agent host sends the person to Coffee Chats. If it runs out, the agent starts the flow again rather than retrying the expired one. An agent should not invent permissions it does not need. A person reading a long list of requests is more likely to deny all of them, and a tool whose permission was not granted returns an error rather than data. The [permissions page](/mcp/scopes.md) lists every permission and the tools each one unlocks; it is generated from the running catalogue, so it is the accurate list rather than a copy kept by hand. ## Staying connected An access token is short-lived. A connection granted `offline_access` also receives a refresh credential, and the host renews the access token in the background so ordinary work does not send the person back to a sign-in page. A refresh credential can be used once. Using it returns a new one and retires the old one, and presenting a retired one ends the whole connection rather than that single credential. An agent must never copy a refresh credential to a second machine, because the second use looks exactly like a stolen credential being replayed. A connection is moved by authorizing again from the new machine. ## The first call The smallest honest first call is `profile.get`. It takes no input, reads only the account that signed in, and changes nothing. If it returns that account's profile, the connection works. ## The signed-in brief Once connected, an agent can fetch a summary of the account it is acting for: `GET https://mcp.coffeechats.me/llms.txt` with the header `Authorization: Bearer` and the access token. It returns a short document naming the student, what currently needs attention, and which tools the granted permissions unlock. Fetching that address without a token returns a pointer back to this flow instead. ## What still waits for a person Some changes are not written when the agent asks for them. The agent records a request, and nothing changes until the person opens a Coffee Chats page and approves exactly what is shown there. The [approvals page](/mcp/approvals.md) explains which tools work this way and what the person sees. Two rules hold regardless of the permissions granted. An agent sends mail to another human only through three tools: a thank-you the person approves in a browser, one outreach draft the person already wrote, and a checked table of the person's own drafts. It cannot invent a recipient or rewrite a draft. An agent does not end its own connection; a person does that on the connections page, and the [revocation page](/mcp/revocation.md) explains what stops immediately afterwards. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.