Connect any MCP-compatible AI client to your Blindata tenant to explore, search, and manage your data through natural language.

MCP Server URL

Every request targets your tenant through this endpoint:

https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/

Connections must use HTTPS.

Authentication

All MCP requests must be authenticated. The method you use depends on your client type and how your organization manages identity.

The MCP server validates every request against the Blindata API. The tenant UUID in the URL path scopes the request to your tenant.

1. OAuth 2.0 — Blindata Authorization Server (recommended)

The recommended approach for desktop AI clients. When you connect, your AI app opens a browser so you can sign in with your usual company account (Microsoft Entra ID, Google, and others). Blindata acts as the OAuth Authorization Server and federates that login — you do not put your password in the AI client.

Before that login can work, Blindata must recognize your AI app. There are three ways to set that up:

Regardless of which option your tenant uses, the end-user experience is the same: the client opens a browser, you sign in and grant consent, and subsequent MCP requests carry an Authorization: Bearer <token> header. The client stores and refreshes that token automatically.

Blindata treats all MCP OAuth clients as public clients. Authentication uses the authorization code flow with PKCE — Blindata does not issue client secrets.

How each option works

MCP clients discover Blindata’s OAuth configuration automatically from the MCP server URL (RFC 9728 Protected Resource Metadata). The difference between the three options is how the AI client proves its identity to Blindata before the login flow starts.

Client ID Metadata Documents (CIMD)

CIMD is an OAuth client registration method defined in the MCP authorization specification. Instead of pre-creating a client record in Blindata, the AI app uses an HTTPS URL as its client_id. That URL points to a JSON document hosted by the app vendor (for example, Anthropic for Claude Desktop) containing the app’s name, redirect URIs, and other OAuth metadata.

When you click Connect, Blindata fetches that document, validates it, and proceeds with the OAuth authorization code flow with PKCE. No OAuth Client ID needs to be configured manually on either side.

Claude Desktop uses CIMD when connecting through Customize → Connectors. Anthropic’s clients select this path when Blindata’s authorization server advertises CIMD support. This is the validated setup for Claude Desktop.

Dynamic Client Registration (DCR)

DCR is the older automatic registration method. When you first connect, the AI client sends a registration request to Blindata’s registration_endpoint, creating a new OAuth client record at runtime. Blindata returns a client_id; the client then completes the browser login using PKCE. No client secret is issued.

Cursor and VS Code typically use DCR when you add the Blindata MCP server URL to their configuration. Each client instance may create its own registration, so switching machines can produce separate client records.

Pre-registered client

When automatic registration is not enabled — or when your organization prefers explicit control — a tenant administrator creates the OAuth client manually in Settings in the Blindata web interface. Blindata issues an OAuth Client ID only.

The end user enters that value in the AI client (for example, Advanced settings in Claude Desktop’s Connectors UI). Claude authenticates as a public client with PKCE — leave the Client Secret field empty. Per Claude’s connector authentication docs , the Client Secret field is optional and only needed when the authorization server requires confidential-client authentication; Blindata does not. This path does not require CIMD or DCR to be enabled on the tenant.

Tenant security settings

CIMD and DCR are tenant-level security settings. Both are disabled by default. To enable one or both, contact Blindata support — they cannot be turned on from the Blindata UI.

2. API key authentication

The simplest method. Send your Blindata account credentials as request headers on every MCP call:

• x-bd-user — your username or email
• x-bd-apikey — your API key

API keys can be managed from the Blindata web interface. This method does not require OAuth configuration on the tenant, but credentials must be stored in your client configuration.

3. Bearer token — Blindata-issued

Send a Bearer token issued by Blindata in the Authorization header:

Authorization: Bearer <your-token>

Use this when your custom client already holds a Blindata access token — for example, one obtained through the Blindata OAuth Authorization Server flow or an existing Blindata session. The token must be valid for your tenant and not expired.

4. External identity provider token (Entra ID and OIDC)

For enterprise custom integrations, you can authenticate with an access token issued directly by your identity provider (Microsoft Entra ID, Google, or a custom OIDC provider configured on your tenant):

Authorization: Bearer <idp-access-token>

The token must include the Blindata audience — the scope or resource must target your Blindata instance (e.g. https://your-company.blindata.io/.default). The Blindata API validates the token the same way as for the main application.

For provider-specific configuration (SSO setup, daemon apps, token claim verification), refer to the Authentication Methods Guide .

Custom clients

If you are building your own MCP client or backend integration (not a desktop tool like Cursor or Claude), you have several authentication options:

• MCP OAuth discovery — implement the same flows as desktop clients, adhering to DCR or CIMD as described in How each option works . Your client discovers Blindata’s authorization server from the MCP URL and completes the browser or device login flow.
• Direct Bearer token — obtain an access token yourself and send it on every request, without going through MCP OAuth discovery. Common choices are a Blindata-issued token (method 3 above), an Entra ID access token (method 4 below), or another OIDC provider token configured on your tenant.
• API key — send x-bd-user and x-bd-apikey headers (method 2 above).

The sections below cover Entra ID and OIDC Bearer token setup in detail. For API keys and Blindata-issued tokens, use the header patterns described in the authentication methods above.

Entra ID — user-delegated applications

For interactive applications where a user signs in through Entra ID:

1. Register your application in the Entra ID portal
2. Request an access token with the Blindata audience — the scope or resource must target your Blindata instance (e.g. https://your-company.blindata.io/.default)
3. Include the token in every MCP request:

Authorization: Bearer <entra-access-token>

The user must exist in Blindata and be linked to their Entra identity. See SSO With Microsoft Entra ID for SSO setup and admin consent requirements.

Entra ID — daemon and service principal applications

For unattended integrations (batch jobs, internal services, custom agents), use the OAuth2 client credentials flow:

1. Register a service principal in Entra ID and assign the required application permissions
2. Create a corresponding Blindata credential with username format msazure:{object_id}@{azure_tenant_id}
3. Obtain an access token using client credentials, requesting scope {your-blindata-host}/.default
4. Send the token as a Bearer header on MCP requests

Step-by-step instructions, token claim verification, and curl examples are in Authenticating a Daemon App with a Service Principal .

Other OIDC providers

For on-premise or dedicated deployments with a custom OIDC provider, the same Bearer token pattern applies: obtain an access token from your provider with the correct Blindata audience and include it in the Authorization header. See Custom OIDC Provider for configuration details.

Desktop AI Clients

The configuration format depends on your client. Use the section that matches your tool.

Cursor

1. Open Settings → Tools & MCP and click Add Custom MCP
2. Add the configuration below to mcp.json

OAuth

{
  "mcpServers": {
    "blindata": {
      "url": "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/"
    }
  }
}

On first use, the server appears as Needs authentication. Click Connect to open the browser for Blindata login and consent. Cursor stores and refreshes the Bearer token automatically.

API key

{
  "mcpServers": {
    "blindata": {
      "url": "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/",
      "headers": {
        "x-bd-user": "{your-email}",
        "x-bd-apikey": "{your-api-key}"
      }
    }
  }
}

Claude Desktop

Claude Desktop cannot use a remote url in claude_desktop_config.json — that file only launches local stdio processes. For remote Blindata MCP, use the Connectors UI or the mcp-remote bridge below.

OAuth — Connectors UI (recommended)

Claude connects to remote MCP servers through Customize → Connectors (individual plans) or Organization settings → Connectors (Team and Enterprise). Anthropic’s documentation covers the full flow: Get started with custom connectors using remote MCP .

1. Open Customize → Connectors and click Add custom connector
2. Enter the Blindata MCP server URL:

   https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/
   

3. Choose how your tenant is set up (see How each option works above for background):

Automatic login (CIMD enabled) — leave Advanced settings empty. Claude Desktop identifies itself to Blindata via CIMD (see above) and opens a browser login when you click Connect. No OAuth Client ID to copy from Blindata.

Pre-registered client — if CIMD is not enabled on your tenant, your administrator creates an OAuth client in Settings in the Blindata web interface and shares the OAuth Client ID with you. In Claude Desktop, open Advanced settings, enter the OAuth Client ID, and leave Client Secret empty — Claude supports public clients with PKCE, and Anthropic documents the Client Secret field as optional unless the authorization server requires confidential-client authentication.

4. Click Add, then Connect to complete the browser login and consent flow
5. Enable the connector per conversation via the + button → Connectors

API key or Developer config — mcp-remote

When OAuth is not enabled on your tenant, or when you prefer the Developer config file, use the mcp-remote package as a local bridge. Requires Node.js 16+.

1. Install the package globally:

   npm install -g mcp-remote
   

2. Verify the installation:

   mcp-remote --version
   

3. Open Claude Desktop and navigate to Menu → File → Settings
4. In the Developer section, click Edit Config — this opens your file explorer with claude_desktop_config.json
5. Add one of the configurations below
6. Fully quit Claude Desktop (Menu → File → Exit, or terminate the process in your Task Manager) and reopen it to reload the configuration

OAuth (automatic login enabled on tenant):

{
  "mcpServers": {
    "blindata": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/"
      ]
    }
  }
}

API key (OAuth disabled on tenant):

{
  "mcpServers": {
    "blindata": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/",
        "--header",
        "x-bd-apikey:{your-api-key}",
        "--header",
        "x-bd-user:{your-email}"
      ]
    }
  }
}

Visual Studio Code

OAuth

{
  "servers": {
    "blindata": {
      "url": "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/",
      "type": "http"
    }
  },
  "inputs": []
}

On first connection, VS Code opens a browser window for Blindata login and consent.

API key

{
  "servers": {
    "blindata": {
      "url": "https://{your-blindata-host}/mcp-api/v1/tenant/{tenantUuid}/mcp/",
      "type": "http",
      "headers": {
        "x-bd-user": "{your-email}",
        "x-bd-apikey": "{your-api-key}"
      }
    }
  },
  "inputs": []
}

Other AI Clients

If your client supports a remote url field, point it at the MCP server URL and follow its OAuth or header-based authentication flow. If the config only accepts command and args (stdio), use mcp-remote as a bridge — same pattern as Claude Desktop above.

Configuration files are typically located under:

• Windows: %APPDATA%
• macOS: ~/Library/Application Support/
• Linux: ~/.config/

Troubleshooting

OAuth connection fails

• Claude Desktop: confirm CIMD has been enabled (contact Blindata support), or use a pre-registered client created in Settings
• Cursor / VS Code: confirm DCR has been enabled (contact Blindata support), or use a pre-registered client created in Settings
• For Claude Desktop with a pre-registered client, verify the OAuth Client ID in Advanced settings matches the client in Blindata Settings, and that Client Secret is left empty
• Verify the MCP server URL contains the correct tenant UUID

Claude Desktop: server not connecting

• Do not put a url field in claude_desktop_config.json — use Customize → Connectors for OAuth, or mcp-remote for the Developer config
• If automatic login is not enabled, use a pre-registered client (created in Blindata Settings) via Advanced settings in Connectors, or fall back to mcp-remote with API key headers
• The MCP server must be reachable from the public internet — Claude connects from Anthropic’s infrastructure, not your local machine
• Check Settings → Developer → Open Logs Folder for mcp-remote errors

Tools not appearing

• Cursor: Save mcp.json again, or click Connect if the server shows Needs authentication
• Claude Desktop: Navigate to the Developer section multiple times, or fully quit and relaunch after config changes

Custom client: Entra token rejected

• Verify the token audience targets your Blindata instance ({your-blindata-host}/.default)
• For daemon apps, confirm the Blindata user exists as msazure:{object_id}@{azure_tenant_id} and that oid equals sub in the token
• Check that iss starts with https://login.microsoftonline.com/ — see the Entra daemon guide