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

Field	Required	Description
Endpoint URL	Yes	The full endpoint URL of your MCP server.
Authentication Type	Yes	How the Aisera Platform authenticates with the MCP server. Options: None, Bearer Token, OAuth.
Mode	Yes	Controls token sharing. Service Shared Token: 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.
Transport Type	Yes	The wire protocol used to communicate with the upstream server. Streamable HTTP: the recommended protocol (MCP specification 2025-03-26 and later).
Customer Headers	No	A JSON object of static headers to include on every upstream MCP request (for example, {"X-API-Key": "your-key"}). The reserved headers Authorization and Proxy-Authorization are not permitted as keys.

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

Field	Required	Description
Bearer Token	Yes	A static API key or secret token issued by the MCP server provider. The Aisera Platform passes this as a Bearer token in the Authorization 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.

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.

Field	Required	Description
OAuth Client Registration	Yes	Controls how the Aisera Platform presents itself to the authorization server. Manual (pre-registered client): use when you have registered an OAuth application with the provider in advance and received a client_id and client_secret. Auto (DCR): 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.
Well-known URL	No	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 Authorization URL and Access Token URL 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.
OAuth Client ID	Yes (Manual)	The client_id issued by the authorization server at app registration. Required when OAuth Client Registration is set to Manual.
OAuth Client Secret	Yes (Manual)	The client_secret paired with the OAuth Client ID. Leave blank for public clients using Proof Key for Code Exchange (PKCE) only.
Authorization URL	Yes (Manual)	The provider's authorization endpoint (for example, https://provider.com/oauth/authorize). Must be provided together with Access Token URL. When both are present, endpoint discovery via the well-known URL is skipped entirely.
Access Token URL	Yes (Manual)	The provider's token endpoint (for example, https://provider.com/oauth/token). Must be provided together with Authorization URL.

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

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