Skip to main content
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.

​
Authentication methods

An MCP source declares how it authenticates through the authType field. Synti supports three approaches for the connection itself:
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.

​
Local (stdio) servers

A local stdio server 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:
Synti keys each secret by a three-part identifier—authentication type, workspace ID, and source slug. That scoping keeps credentials from one workspace from ever being visible to another, even if two workspaces connect the same service.
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.

​
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:
    Synti will prompt you to re-authenticate each source the next time you use it.

​
Good practices

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.
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.
Rotate tokens for sensitive services periodically. Because secrets are scoped per source, rotating one never disturbs the others.
Credentials govern the connection; what the agent is then allowed to do with a server’s tools is governed separately by Permissions.