> For the complete documentation index, see [llms.txt](https://docs.aisera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aisera.com/aisera-platform/what-can-my-bot-do/mcp-client/mcp-server-configuration-reference.md).

# MCP server configuration reference

Field-level reference for all settings in the New MCP Server wizard and the Edit MCP Server panel.

Reference for all fields in the **New MCP Server** wizard and the **Edit MCP Server** panel.

## Step 1: Connect

### Connection fields

<table><thead><tr><th width="210">Field</th><th width="113">Required</th><th>Description</th></tr></thead><tbody><tr><td><strong>Endpoint URL</strong></td><td>Yes</td><td>The full endpoint URL of your MCP server.</td></tr><tr><td><strong>Authentication Type</strong></td><td>Yes</td><td>How the Aisera Platform authenticates with the MCP server. Options: <strong>None</strong>, <strong>Bearer Token</strong>, <strong>OAuth</strong>.</td></tr><tr><td><strong>Mode</strong></td><td>Yes</td><td>Controls token sharing. <strong>Service Shared Token</strong>: the Aisera Platform uses a single credential for all requests from your tenant. Complete the OAuth flow once; the token is shared across all users of this server.</td></tr><tr><td><strong>Transport Type</strong></td><td>Yes</td><td>The wire protocol used to communicate with the upstream server. <strong>Streamable HTTP</strong>: the recommended protocol (MCP specification 2025-03-26 and later).</td></tr><tr><td><strong>Customer Headers</strong></td><td>No</td><td>A JSON object of static headers to include on every upstream MCP request (for example, <code>{"X-API-Key": "your-key"}</code>). The reserved headers <code>Authorization</code> and <code>Proxy-Authorization</code> are not permitted as keys.</td></tr></tbody></table>

#### None

No additional fields. The Aisera Platform connects to the MCP server URL directly without sending credentials. The server responds to all requests without validating caller identity.

Use this only for public or non-sensitive data endpoints. Do not use this authentication type for servers that access private data or perform write operations.

#### Bearer Token fields

<table><thead><tr><th width="150">Field</th><th width="116">Required</th><th>Description</th></tr></thead><tbody><tr><td><strong>Bearer Token</strong></td><td>Yes</td><td>A static API key or secret token issued by the MCP server provider. The Aisera Platform passes this as a Bearer token in the <code>Authorization</code> header on every request. The MCP server validates the key on every request. Treat this value as a secret: store it securely and rotate it if it is compromised.</td></tr></tbody></table>

#### OAuth fields

The Aisera Platform uses OAuth 2.1 as defined in the MCP Authorization Specification (2025-11-25). The OAuth flow is completed once and the Aisera Platform reuses the resulting access token for all requests from your tenant.

<table><thead><tr><th width="237">Field</th><th width="115">Required</th><th>Description</th></tr></thead><tbody><tr><td><strong>OAuth Client Registration</strong></td><td>Yes</td><td>Controls how the Aisera Platform presents itself to the authorization server. <strong>Manual (pre-registered client)</strong>: use when you have registered an OAuth application with the provider in advance and received a <code>client_id</code> and <code>client_secret</code>. <strong>Auto (DCR)</strong>: use when the MCP server supports Dynamic Client Registration (DCR, RFC 7591). The Aisera Platform registers itself with the authorization server at connection time and receives credentials dynamically.</td></tr><tr><td><strong>Well-known URL</strong></td><td>No</td><td>A custom URL for the authorization server's OAuth metadata discovery document. Used when OAuth endpoint discovery runs: in Auto mode, or in Manual mode when <strong>Authorization URL</strong> and <strong>Access Token URL</strong> are not both provided. If both explicit endpoint URLs are provided in Manual mode, discovery is skipped and this field is ignored. If left blank in Auto mode, the Aisera Platform attempts to infer the discovery document from the MCP server's base URL.</td></tr><tr><td><strong>OAuth Client ID</strong></td><td>Yes (Manual)</td><td>The <code>client_id</code> issued by the authorization server at app registration. Required when <strong>OAuth Client Registration</strong> is set to Manual.</td></tr><tr><td><strong>OAuth Client Secret</strong></td><td>Yes (Manual)</td><td>The <code>client_secret</code> paired with the OAuth Client ID. Leave blank for public clients using Proof Key for Code Exchange (PKCE) only.</td></tr><tr><td><strong>Authorization URL</strong></td><td>Yes (Manual)</td><td>The provider's authorization endpoint (for example, <code>https://provider.com/oauth/authorize</code>). Must be provided together with <strong>Access Token URL</strong>. When both are present, endpoint discovery via the well-known URL is skipped entirely.</td></tr><tr><td><strong>Access Token URL</strong></td><td>Yes (Manual)</td><td>The provider's token endpoint (for example, <code>https://provider.com/oauth/token</code>). Must be provided together with <strong>Authorization URL</strong>.</td></tr></tbody></table>

**Authorization URL** and **Access Token URL** must both be provided or both be omitted. Providing only one is a validation error. If only one endpoint is known, use the **Well-known URL** field to let the Aisera Platform discover the other.

### OAuth endpoint discovery order

When the Aisera Platform needs to locate the authorization and token endpoints, it follows this order:

1. **Explicit URLs.** If both **Authorization URL** and **Access Token URL** are supplied, those are used directly. Discovery is skipped.
2. **Well-known URL.** If only the well-known URL is provided, or if neither explicit URL is set, the Aisera Platform fetches the discovery document from that URL to extract the endpoints.
3. **Server-advertised discovery.** If no well-known URL is provided, the Aisera Platform attempts to infer the discovery document from the MCP server's base URL by appending `/.well-known/openid-configuration`.

### OAuth client registration order

When the Aisera Platform determines how to present itself to the authorization server, it follows this order:

1. **Manual (pre-registered).** If `oauth_client_id` is supplied, it is sent directly. Dynamic registration is not attempted.
2. **Auto (DCR).** If the authorization server exposes a `registration_endpoint` in its metadata, the Aisera Platform registers itself dynamically and uses the returned `client_id`. DCR is not universally supported: check the authorization server's OAuth metadata for a `registration_endpoint` field before selecting Auto.

## Step 3: Details and sync

<table><thead><tr><th width="191">Field</th><th width="157">Required</th><th>Description</th></tr></thead><tbody><tr><td><strong>Server Name</strong></td><td>Yes</td><td>The name the server appears under in the Aisera UI. Auto-filled from the connected server. Editable.</td></tr><tr><td><strong>Description</strong></td><td>No</td><td>A text field for notes about the server's purpose or usage.</td></tr><tr><td><strong>Auto Re-sync Tools</strong></td><td>No</td><td>When enabled, the Aisera Platform automatically re-syncs the tool list from the server on a schedule. On by default.</td></tr><tr><td><strong>Re-sync Frequency</strong></td><td>Yes (when Auto Re-sync is on)</td><td>The interval and time of day for automatic re-syncs. Interval options: <strong>Hourly</strong>, <strong>Daily</strong>, <strong>Weekly</strong>, <strong>Monthly</strong>.</td></tr><tr><td><strong>Notify on Sync Error</strong></td><td>No</td><td>When enabled, the Aisera Platform sends an email notification when a sync fails. On by default.</td></tr><tr><td><strong>Pause the server after 3 consecutive sync failures</strong></td><td>No</td><td>When enabled, the server is automatically paused after three consecutive sync failures. Off by default.</td></tr></tbody></table>