> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tylon.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect an editor

> Give your editor one URL and it finds the rest. Tylon's MCP server authenticates you with OAuth 2.0 and PKCE, and you pick which boards the connection reaches.

```text theme={null}
https://api.tylon.app/mcp
```

That is the whole configuration. One address, the same one for everybody.

## What happens after you paste it

Nothing you have to do. The editor calls the endpoint, gets a `401` naming a metadata document, reads it, finds the authorization server, registers itself, and starts the flow. Every step is a document.

<Steps>
  <Step title="Your browser opens">
    Tylon asks who you are, the way it always does. This is your own sign-in — the editor never sees it.
  </Step>

  <Step title="You pick the boards">
    The consent screen lists the boards you work on and what you hold on each. Tick one or several: somebody who works on three products should not have to authorize three times to run their day from one terminal.
  </Step>

  <Step title="You choose read or write">
    `workspace:read` reads. `workspace:write` also comments and writes down a repository's conventions — nothing that moves Git.
  </Step>
</Steps>

## What the connection can do

**Exactly what you can, and no more.** The role is read from your membership on every single call, per board. A colleague demoted to viewer this morning is a viewer to their editor this afternoon, and somebody removed from a board stops reaching it without anybody remembering that they once connected something.

This is the deliberate difference from an [API credential](/api-reference/authentication), which holds a role of its own because it is nobody.

## Working across several boards

When a connection reaches more than one, tools that are about a board take a `workspace` argument — `acme/product`, or just `product` when nothing else you reach answers to it. Leave it out with several and the tool asks rather than guessing.

## The details, for a client that wants them

<ResponseField name="Authorization server metadata" type="RFC 8414">
  `https://api.tylon.app/.well-known/oauth-authorization-server`
</ResponseField>

<ResponseField name="Protected resource metadata" type="RFC 9728">
  `https://api.tylon.app/.well-known/oauth-protected-resource/mcp`
</ResponseField>

|                       |                                       |
| --------------------- | ------------------------------------- |
| Grant types           | `authorization_code`, `refresh_token` |
| PKCE                  | `S256`, required                      |
| Client authentication | `none` — do not expect a secret       |
| Registration          | dynamic, RFC 7591                     |
| Scopes                | `workspace:read`, `workspace:write`   |

Both refusals are capabilities written as refusals: a client reading the metadata learns it must bring PKCE and must not expect a client secret.

## Disconnecting

Revoke the connection wherever you manage your connections. Tokens stop working immediately — there is a revocation endpoint, and the editor will ask to authorize again the next time you use it.