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

# MCP Authentication

> How Synti authenticates MCP servers and stores their credentials securely on your machine.

Most useful MCP servers require credentials, and Synti handles them so that secrets stay encrypted on your machine and never end up in a config file. This page covers the authentication methods MCP servers support, how Synti stores and scopes credentials, and how to manage them over time. For adding servers, see [Connecting servers](/sources/mcp-servers/connecting-servers).

## Authentication methods

An MCP source declares how it authenticates through the `authType` field. Synti supports three approaches for the connection itself:

| `authType` | Best for                        | How it works                                                                                             |
| ---------- | ------------------------------- | -------------------------------------------------------------------------------------------------------- |
| `oauth`    | Interactive, user-scoped access | Opens a browser to authorize. Tokens refresh automatically; you re-authenticate only if a refresh fails. |
| `bearer`   | Static tokens and API keys      | Synti prompts for the credential on first use and encrypts it locally.                                   |
| `none`     | Public servers                  | No credentials required.                                                                                 |

<Tip>
  Prefer OAuth over a static bearer token when a server offers it. OAuth gives you scoped, revocable access and refreshes on its own, so there's no long-lived key sitting on disk.
</Tip>

### Local (stdio) servers

A [local stdio server](/sources/mcp-servers/overview) runs as a process on your machine, so it usually needs no network authentication of its own. When such a server needs a secret—say, an API key for a service it calls—it typically reads it from an environment variable or a config file that you supply in the source's launch configuration.

## How credentials are stored

Credentials are encrypted and written to a single local file, never into `config.json`:

```text theme={null}
~/.synti/credentials.enc
```

Synti keys each secret by a three-part identifier—authentication type, workspace ID, and source slug. That scoping keeps credentials from one [workspace](/go-further/workspaces) from ever being visible to another, even if two workspaces connect the same service.

<Warning>
  Because credentials are encrypted, you cannot read the stored values back. You can confirm what is stored—but not the secret itself—through Synti's `/debug` command.
</Warning>

## Managing credentials

* **See what's stored.** Run `/debug` to list which sources have credentials, without revealing the values.
* **Remove one source's credentials.** Delete the source; its scoped credentials go with it.
* **Clear everything.** Remove the encrypted store entirely:

  ```bash theme={null}
  rm ~/.synti/credentials.enc
  ```

  Synti will prompt you to re-authenticate each source the next time you use it.

## Good practices

<AccordionGroup>
  <Accordion title="Prefer OAuth where available">
    Scoped, revocable, and self-refreshing—OAuth avoids a long-lived key on disk and lets you revoke access from the provider side at any time.
  </Accordion>

  <Accordion title="Limit token scope">
    When you must use a static token, mint it with only the permissions the agent actually needs. A read-only token is a safer default than a full-access one.
  </Accordion>

  <Accordion title="Rotate sensitive credentials">
    Rotate tokens for sensitive services periodically. Because secrets are scoped per source, rotating one never disturbs the others.
  </Accordion>
</AccordionGroup>

Credentials govern the connection; what the agent is then allowed to do with a server's tools is governed separately by [Permissions](/core-concepts/permissions).