SkaleData DocsConnect other MCP clients with an API key
Connect Claude Code or another MCP client to the SkaleData MCP gateway with an org-wide API key, and what changes when the client acts as a key instead of a person.
Any MCP client that can send an HTTP header can connect to the SkaleData MCP gateway with an organization API key. Use this for Claude Code, scripts, and other clients that can't sign in to SkaleData as a person.
To connect Claude chat on claude.ai, sign in as yourself instead: see Connect Claude chat to SkaleData.
Before you begin
- An org admin has turned on MCP data egress for your organization. While it's off, the gateway refuses every tool call. Read What data leaves your cloud first.
- You have an org-wide API key with the
fullscope. An org admin creates one in the SkaleData console, under Organization > API Keys. See API keys. - For Superset tools, the app runs the MCP server. Someone with the operator role or higher turns on Run the MCP server in the app's Resources tab.
Connect a client
The gateway uses the streamable HTTP transport at this URL:
https://mcp.skaledata.run/mcpSend the key on every request as a bearer token:
Authorization: Bearer sdk_...For example, to add the gateway to Claude Code, with the key in the SKALEDATA_API_KEY environment variable:
claude mcp add --transport http skaledata https://mcp.skaledata.run/mcp \
--header "Authorization: Bearer $SKALEDATA_API_KEY"Other clients take the same URL and header in their own configuration.
Which keys work
| Key | Result |
|---|---|
Org-wide key with the full scope | Works. |
| Org-wide key with narrower scopes | Connects, but every tool call is refused, because the gateway needs the full scope to check your organization's MCP data egress setting. |
| Workspace API key | Refused with 403. Workspace keys can't use the gateway. |
| Revoked, expired, or unknown key | Refused with 401. A key you revoke fails from its next tool call. |
How a key differs from signing in as a person
An API key isn't a person, so the gateway treats it as a shared service identity:
- One identity for every key. In an app such as Superset, every API-key call runs as the same SkaleData service user,
api-key@skaledata.run. Charts and dashboards that a key creates belong to that service user, not to the person who ran the client. - No saved queries.
superset_save_sql_queryrefuses API keys, because a saved query is visible only to the user who saves it, so a query saved as the service user would be hidden from you. To save a query, usesuperset_open_sql_lab_with_contextto open the query in SQL Lab, and then save it yourself. - No Airflow tools. Airflow tools refuse API keys, because Airflow applies a person's role for the app, and a key isn't a person. To use them, connect Claude chat with your SkaleData account.
- No Airbyte tools. Airbyte tools refuse API keys. Airbyte records every change as one built-in user, so SkaleData's audit record is the only record of who made a change, and it must name a person. To use them, connect Claude chat with your SkaleData account.
- The audit log names the key. SkaleData records each change that a key makes with the key's ID, not a person's email address. See What the audit log records.
Everything else works as it does for a signed-in person: your organization's MCP data egress setting, each app's MCP and raw SQL settings, and the audit record before every change all apply.
Connect Claude chat to SkaleData
Add SkaleData as a custom connector in Claude, sign in as yourself, and let Claude work with your clusters, apps, Superset, Airflow, and Airbyte with your own permissions.
What data leaves your cloud
What an AI client connected through the SkaleData MCP gateway receives, what your organization's MCP data egress setting controls, and what SkaleData records.