# White-label the MotherDuck MCP server
> Wrap the remote MCP server behind your own MCP server so your customers get SQL, Guides, Dives, and Flights under your brand.
Run your own MCP server to give customers an analytics connection under your brand. Your server authenticates users, maps each tenant to a MotherDuck [service account](/key-tasks/service-accounts-guide/), and forwards selected tools to the [managed MCP server](/sql-reference/mcp/).

Use this for a multi-tenant product, reseller platform, or client analytics service. Customers sign in to your product and work with their permitted data through your tool names and guidance. If you only need to connect your own team, follow [Connect to the MotherDuck MCP server](/key-tasks/ai-and-motherduck/mcp-setup/) instead.

## Prerequisites

Before starting, ensure you have:

- A MotherDuck organization on a plan that includes [service accounts](/key-tasks/service-accounts-guide/create-and-configure-service-accounts/). Embedding Dives in your own app (Path B below) requires the **Business plan**.
- If you automate provisioning, a backend credential with permission to create service accounts and tokens through the [REST API](/sql-reference/rest-api/motherduck-rest-api/). Keep this separate from the credentials used to query tenant data.
- An authentication method supported by your target MCP clients. For customers signing in to your product, use an identity provider with an MCP-compatible OAuth flow.
- A backend that can host a remote MCP server. The upstream connection example uses [FastMCP](https://gofastmcp.com/) for Python. Other MCP SDKs have their own session and result-handling APIs.
- A backend secret store for per-tenant MotherDuck tokens and an authorized mapping from application users to tenants.

## How the proxy fits together

```mermaid
flowchart LR
    Client(["AI client"]):::green -->|Product<br/>token| Wrapper["Your MCP<br/>server"]:::watermelon
    Wrapper -->|Tenant<br/>token| Upstream["MotherDuck<br/>MCP"]
```

Your server verifies tenant membership and selects that tenant's service-account token. MotherDuck enforces the service account's data permissions.

Three properties make this work:

1. **The remote MCP server accepts a Bearer token instead of OAuth.** Any client, including your server, can connect with `Authorization: Bearer <motherduck_token>` over the streamable-HTTP transport. See the Bearer token note in [Connect to the MotherDuck MCP Server](/key-tasks/ai-and-motherduck/mcp-setup/).
2. **Service accounts give you per-tenant isolation.** Give each tenant a service account with access only to that tenant's databases or shares. Selecting a database argument or filtering a catalog listing does not restrict cross-database SQL. See [Create and configure service accounts](/key-tasks/service-accounts-guide/create-and-configure-service-accounts/).
3. **Your proxy owns the tool surface.** You decide which MotherDuck tools are forwarded, what they're called, how they're described, and which parameters the agent may set.

### Compare the approaches

| Approach | Pros | Cons |
|---|---|---|
| **Proxy the remote server** (this page) | Full remote tool set including Dives, Flights, and Guides. MotherDuck runs and upgrades the server. You maintain auth plus a thin tool layer. Per-tenant token isolation | One extra network hop. Integration tests must catch upstream schema changes. MCP App forwarding for Dives takes more work than plain tool forwarding |
| **Fork the [local MCP server](https://github.com/motherduckdb/mcp-server-motherduck)** | Fully customizable, self-hosted, no dependency on remote tool schemas | A separate implementation with its own tool set. Verify the capabilities you need. You own upgrades and hosting |
| **Point users at `api.motherduck.com/mcp` with a shared API key** (the Copilot Studio tab in the [setup guide](/key-tasks/ai-and-motherduck/mcp-setup/)) | No code | Not white-labeled: MotherDuck-named server, tools, and instructions. One shared identity, so no per-user attribution |

## Step 1: Map users to service accounts

Your proxy needs a deterministic path from *authenticated user* to *MotherDuck token*.

1. **Authenticate the user** with your identity provider. Follow the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization), including resource discovery, audience validation, and a client registration method your target clients support. Dynamic client registration is one option, not a universal requirement. A website sign-in flow alone does not implement MCP authentication.
2. **Resolve the tenant** from verified identity and membership. If a user can select several tenants, authorize the selection. A tenant ID supplied in a URL or tool argument is not proof of membership.
3. **Look up the tenant's service-account token** in your secret store. Never return this token to the client. Create tokens with [Create an access token for a user](/sql-reference/rest-api/users-create-token/) and rotate them with [Invalidate a user access token](/sql-reference/rest-api/users-delete-token/).
4. **Open an upstream MCP client session** to `https://api.motherduck.com/mcp` with that token. You can reuse it within the authorized session or open and close it for each call. If you pool sessions, separate them by tenant and credential, manage concurrent access, and invalidate them when tokens rotate or access is revoked.

For read-only database access, issue each service account a [read scaling token](/key-tasks/authenticating-and-connecting-to-motherduck/read-scaling/) and don't forward `query_rw`. See [Restricting to read-only access](/key-tasks/ai-and-motherduck/securing-read-only-access/). Read scaling is eventually consistent, so consider data freshness. Review Guide, Dive, and Flight mutations separately from SQL access.

Validate your product's credential at the proxy, then select the MotherDuck token from your backend mapping. Don't forward the product's OAuth token upstream or expose the MotherDuck token to customers. Controlled backend integrations can use your own API keys if the client supports them, but the proxy must still authenticate and authorize callers.

All MotherDuck-side activity (query history, Dive ownership, billing) is attributed to the tenant's service account, not to the individual end user. If you need per-user attribution inside a tenant, log the user ID on your side alongside each forwarded call (see [Step 5](#step-5-log-the-question-not-only-the-sql)).

## Step 2: Choose which tools to forward

The remote server exposes tools in four families. Forward only what your users need. Enforce that allowed set both in tool listings and when dispatching calls. Reject direct calls to unexposed tools and avoid a generic pass-through tool that accepts an arbitrary upstream tool name.

| Family | Tool | Forward? | Notes |
|---|---|---|---|
| Core | [`query`](/sql-reference/mcp/core/query) | **Yes** | The workhorse. Inherits the 2,048-row / 50,000-character result cap and the 55-second timeout. |
| Core | [`list_databases`](/sql-reference/mcp/core/list-databases), [`list_tables`](/sql-reference/mcp/core/list-tables), [`list_columns`](/sql-reference/mcp/core/list-columns), [`search_catalog`](/sql-reference/mcp/core/search-catalog) | **Yes** | Discover the data model before writing SQL. |
| Core | [`list_views`](/sql-reference/mcp/core/list-views), [`list_macros`](/sql-reference/mcp/core/list-macros) | Optional | Useful if tenant databases ship views or macros as a semantic layer. |
| Core | [`list_shares`](/sql-reference/mcp/core/list-shares) | Usually no | Exposes MotherDuck share URLs (`md:_share/...`). Attach shares to the service account ahead of time instead. |
| Core | [`query_rw`](/sql-reference/mcp/core/query-rw) | Usually no | Only if your product lets end users change data. |
| Core | [`ask_docs_question`](/sql-reference/mcp/core/ask-docs-question) | **No** | Answers come from MotherDuck and DuckDB documentation and name MotherDuck throughout. |
| Guides | [`get_query_guide`](/sql-reference/mcp/guides/get-query-guide), [`list_guides`](/sql-reference/mcp/guides/list-guides), [`get_guide`](/sql-reference/mcp/guides/get-guide) | **Yes** | The read path for your tenants' semantic layer. See [Step 3](#step-3-forward-tenant-guides-and-replace-the-built-in-guides). |
| Guides | [`create_guide`](/sql-reference/mcp/guides/create-guide), [`update_guide`](/sql-reference/mcp/guides/update-guide), [`edit_guide_content`](/sql-reference/mcp/guides/edit-guide-content), [`update_guide_metadata`](/sql-reference/mcp/guides/update-guide-metadata), [`set_guide_access`](/sql-reference/mcp/guides/set-guide-access) | Optional | Authorize edits and enforce tenant-private visibility. Keep organization-wide access changes out of tenant-facing tools. |
| Dives | [`get_dive_guide`](/sql-reference/mcp/dives/get-dive-guide), [`save_dive`](/sql-reference/mcp/dives/save-dive), [`update_dive`](/sql-reference/mcp/dives/update-dive), [`list_dives`](/sql-reference/mcp/dives/list-dives), [`read_dive`](/sql-reference/mcp/dives/read-dive), [`view_dive`](/sql-reference/mcp/dives/view-dive), [`share_dive_data`](/sql-reference/mcp/dives/share-dive-data), [`delete_dive`](/sql-reference/mcp/dives/delete-dive) | Optional | See [Step 4](#step-4-choose-how-dives-render). Do not expose `share_dive_data` to tenants that share one MotherDuck organization. It shares their databases with that organization. |
| Flights | [`get_flight_guide`](/sql-reference/mcp/flights/get-flight-guide), [`create_flight`](/sql-reference/mcp/flights/create-flight), [`update_flight`](/sql-reference/mcp/flights/update-flight), [`run_flight`](/sql-reference/mcp/flights/run-flight), [`list_flights`](/sql-reference/mcp/flights/list-flights), [`get_flight`](/sql-reference/mcp/flights/get-flight), and the remaining `*_flight*` tools | Usually no | [Flights](/concepts/flights) are scheduled Python jobs on MotherDuck compute: an operator feature, rarely one to hand to a tenant's end users. If you expose them, authorize their runtime credentials, schedules, and data access separately from the interactive query connection. |

Rewrite two things in every forwarded tool:

- **Name and description.** Call the tool whatever fits your product (`query` → `run_sql`, `save_dive` → `save_dashboard`). Use your product vocabulary in descriptions and update references to renamed tools. Preserve required technical identifiers such as `@motherduck/react-sql-query` and `REQUIRED_DATABASES`.
- **Server instructions.** The remote server ships MotherDuck's [query guidelines](https://app.motherduck.com/assets/docs/mcp_server_instructions.md) as MCP `instructions`. Your proxy's `instructions` field replaces that. Copy the DuckDB SQL guidance you want and drop the branding.

## Step 3: Forward tenant Guides and replace the built-in guides

[Guides](/key-tasks/guides/) are markdown documents the agent reads before writing SQL. Separate tenant-authored business context from the built-in technical instructions.

### Forward tenant Guides

Metric definitions, join conventions, and business glossaries are the ontology layer your tenants will want. Expose the discovery flow `get_query_guide` → `list_guides` → `get_guide`. Review built-in navigation text and tool references for your product vocabulary, while preserving authorized tenant content. Design around two visibility rules:

- `access: "user"` Guides are private to the service account that created them. This is the natural scope for **per-tenant** Guides. Create them while connected as that tenant's service account.
- `access: "organization"` Guides are visible to **every** service account in your MotherDuck organization, which means every tenant. Use this level only for content that's safe to show all tenants, for example your platform's shared data model. Setting it is admin-permission gated.

A private Guide belongs to the MotherDuck identity, not to one person using your product. Everyone using a tenant's service account shares that identity. Keep individual preferences in your application, keyed by tenant and authenticated user, and combine only that person's preferences with tenant guidance. A topic named after a user does not provide an access boundary.

Use tenant Guides for fiscal calendars, revenue definitions, valid join paths, and dashboard styles. Attach [catalog references](/key-tasks/guides/#attach-references-to-a-guide) so table exploration and catalog search can surface relevant context.

For example, create this Guide through the tenant service account:

```json
{
  "title": "Dashboard style",
  "description": "Colors and number formats for this customer's dashboards",
  "topic": "dives",
  "access": "user",
  "content": "Use navy and teal. Label currency values in EUR. Use compact numbers in KPI cards and full values in tooltips."
}
```

### Replace the built-in guides

[`get_dive_guide`](/sql-reference/mcp/dives/get-dive-guide) and [`get_flight_guide`](/sql-reference/mcp/flights/get-flight-guide) return the system prompts MotherDuck ships for building Dives and Flights. They explain the technical contract, but they're written for MotherDuck users and contain product-specific instructions. Serve an adapted version for the capabilities your product exposes.

Your replacement `get_dive_guide` should:

1. **Keep every technical requirement** from the MotherDuck Dive guide: the [`useSQLQuery`](/sql-reference/motherduck-sql-reference/dives/use-sql-query) hook, `REQUIRED_DATABASES`, data-type conversion rules, available libraries, `useDiveState`, and `exportAs`. Drift can cause validation failures or errors when a Dive renders.
2. **Replace the design-system section** with your brand: colors, typography, chart defaults, number formatting, and tone.
3. **Adapt explanatory wording** to your product. Keep library names, API identifiers, and data-access semantics intact.
4. **Branch on the `client` parameter** (`claude`, `chatgpt`, `claude_code`, and so on) the same way the upstream tool does.
5. **Include the tenant's `dives`-topic Guide overview** from `list_guides(topic="dives")`, and expose `get_guide` to load the actual content. Listings contain summaries, not the full style instructions. Browse nested topics when relevant.

Keep a diff against the upstream guide in your repo. Review your adapted instructions when upstream tools or component APIs change. Adding a style Guide extends the built-in guidance, but does not remove its branding or change viewer controls.

## Step 4: Choose how Dives render

[Dives](/key-tasks/dives/) are React data apps that query live data. Through MCP, the agent creates them with `save_dive` and `update_dive` and renders them inline with `view_dive`, which returns the Dive source, a `dive_app_url`, and viewer metadata. Hosts that support the **Dive Viewer MCP App** (Claude and ChatGPT) compile and render the Dive client-side. This is the part of white-labeling with the most surface area. There are two paths to consider:

### Path A: Forward the Dive tools and the dive viewer

Your users stay in the chat client and see a live, interactive dashboard as a chat message, with full-screen and export.

| Concern | Where it shows up | What to do |
|---|---|---|
| **MotherDuck links in tool results** | Save, update, and view responses can contain `dive_app_url`, legacy `dive_url` fields, and product-specific `next_steps` | Build a response for your product that preserves warnings and errors. Apply URL and instruction rewrites consistently to model-visible text and structured content, not only one copy of the payload. |
| **"Open in MotherDuck" control in the Dive Viewer frame** | Rendered by the MCP App chrome, not by the Dive code | Removing `dive_app_url` does not remove this control. The viewer builds its navigation URL independently. Use Path B for an application page you control, or validate a separately customized in-chat viewer. |
| **MCP App resource** | The viewer is exposed as an MCP resource, not only a tool response | Forward resource reads, the app MIME type, UI and content security policy metadata, and required viewer tool calls. Preserve `_meta` in its intended viewer channel. It can contain credentials and must not be copied into model-visible text or logs. Test the complete flow in each supported client. |
| **Visibility across tenants** | Dives are visible to all users in the MotherDuck organization by default. Other tenants' service accounts can see that a Dive exists and read its **source**, but can't query its **data** because they lack access to the underlying databases. | `list_dives` lists owned Dives, but that is not a permission boundary for reads by ID. Authorize every read, update, view, and embed operation. `save_dive` has no visibility parameter. |

Source code can contain sensitive labels, SQL, or hardcoded values even if another tenant cannot query the database. Test source and metadata access using a second service account, including SQL access to saved objects if you expose arbitrary queries. Wrapper filtering does not establish private permissions on the underlying Dive. Check the MotherDuck organization boundary before placing confidential tenant Dives in it.

This path reuses the live viewer and keeps users in chat. It requires MCP App support in the client and integration work for resource and viewer tool calls. The built-in viewer retains MotherDuck controls.

### Path B: Render Dives in your own app through embed sessions

For this path, return an application link instead of forwarding `view_dive`:

1. Calls `save_dive` upstream as the tenant's service account and stores the returned Dive ID with the authorized tenant.
2. Returns your stable application URL, such as `https://app.example.com/dashboards/<dashboard_id>`, instead of a MotherDuck link.
3. When someone opens that URL, your application authenticates them and authorizes access to the tenant and Dive.
4. Your backend calls [Create a Dive embed session](/sql-reference/rest-api/dashboards-create-embed-session/) with a credential permitted to create embed sessions. Select the target service account and resources from your authorized tenant mapping.
5. Your frontend receives only the expiring embed session and loads the sandboxed iframe. The long-lived backend token stays on your server. See [Embedding Dives in your web application](/key-tasks/dives/embedding-dives/).

Create the embed session when the authorized viewer opens the page, not when generating the permanent link. This avoids persisting an expiring credential in the URL you return to the chat. A signed-in web session still needs a tenant and Dive authorization check.

Use `required_resources` to map a reusable dashboard to the tenant's permitted databases, and `initial_state` to preconfigure filters or a date range. Derive resource mappings on your backend. UI filters are presentation settings, not access controls. Handle navigation, exports, and state-change messages as described in the embedding guide.

This path gives you control over the surrounding page and works in clients without MCP App support. You host the page, and the user leaves chat to interact with it. The embedding service account must have access to the Dive's data. Follow the embedding guide's dedicated-account guidance to avoid database alias collisions.

To combine them, forward `view_dive` for clients that support the Dive Viewer and return your embed URL as the persistent link in `save_dive` and `update_dive`. The user gets an inline preview in chat and a branded permalink.

## Step 5: Log the question, not only the SQL

MotherDuck's query history shows you the SQL a tenant ran, not the question the user asked. Because you own the tool schemas, you can capture intent at the source by adding a `question` parameter to your query tool:

```json
{
  "type": "object",
  "properties": {
    "sql": {
      "type": "string",
      "description": "Read-only DuckDB SQL to answer the data question."
    },
    "question": {
      "type": "string",
      "minLength": 1,
      "description": "The user's data question that this query helps answer."
    }
  },
  "required": ["sql", "question"],
  "additionalProperties": false
}
```

Record `question` on your backend and forward only `database` and `sql` to MotherDuck's `query` tool. This extra parameter is your proxy's feature, not an upstream tool argument.

Record the authenticated application user and tenant, request ID, timestamp, question, SQL, duration, and outcome. Capture unsuccessful attempts as well as successes, and distinguish transport failures from tool errors. Exclude credentials and result rows by default. Explain the collection to users and define retention and access rules for question and SQL text.

The model supplies the `question` field and can paraphrase the original request. One question can produce several queries, and some questions produce no tool call at all. Treat this as question context for query attempts, not a complete transcript or a count of distinct user questions. If you own the chat interface and need the exact submitted question, capture it there.

### Turn recurring questions into better guides

Use the captured context to find repeated questions, unclear definitions, and queries that often fail. For example, repeated requests for "net sales" may reveal that refunds and discounts need an explicit rule.

Review the definition with a domain owner, validate the SQL, and save a tenant-private Guide with catalog references and a `change_comment` explaining the decision. Check whether subsequent questions produce the intended answer. Keep individual preferences scoped to the person, and review proposed learning before it becomes an authoritative business definition.

This feedback loop is application behavior you build. Guides provide storage and discovery, but don't automatically learn from every MCP conversation.

## Connect a Python tool handler to MotherDuck

The following helper uses FastMCP 4.0.3 to open an upstream session and return the raw MCP result. Install `fastmcp==4.0.3` in your backend's Python environment. Call it from your authenticated query handler with the token and database from your authorized tenant mapping.

```python
from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport
from mcp.types import CallToolResult

async def query_tenant(*, token: str, database: str, sql: str) -> CallToolResult:
    transport = StreamableHttpTransport(
        url="https://api.motherduck.com/mcp",
        headers={"Authorization": f"Bearer {token}"},
    )
    async with Client(transport) as client:
        return await client.call_tool_mcp(
            "query",
            {"database": database, "sql": sql},
        )
```

This is the upstream connection helper, not a complete authenticated server. Your application supplies caller authentication, tenant resolution, tool registration, question capture, and response handling. Its `token` and `database` parameters are backend inputs, not model-visible tool arguments. It opens and closes a session per call, so no mutable client is shared across tenants.

Serialize the raw result with `result.model_dump(by_alias=True, exclude_none=True)` to obtain the MCP field names. Preserve `content`, `structuredContent`, `isError`, and `_meta` when adapting it to your server's tool-result type. Transport failures still raise exceptions. The higher-level FastMCP `call_tool()` method returns an SDK result object, not a dictionary, and raises on tool errors by default. See [FastMCP tool calls and raw protocol access](https://gofastmcp.com/clients/tools).

When a save handler rewrites a dashboard response, read the structured payload or parse its JSON text, check for failure before accessing the Dive ID, and produce consistent text and structured output. Preserve validation errors, warnings, and truncation notices. Replace sharing suggestions with your product's authorized next steps without granting broader access or hiding data-access problems.

Add integration checks for the upstream schemas and complete result envelopes. For Dives, test viewer resources and follow-up calls as well as the initial tool response.

## Verify the setup

1. Connect your MCP server in Claude or ChatGPT as a test user for one tenant.
2. Ask "What tables do I have?" You should see only that tenant's tables, returned under your tool names.
3. Ask a question that needs a metric definition from a tenant Guide. The agent should call your forwarded `get_query_guide` and `get_guide` before writing SQL.
4. Ask for a dashboard. The agent should call your replacement guide under the name your proxy exposes, then save. The link should open your authorized application page (Path B), or the live viewer should render with the controls you have verified (Path A).
5. Connect as a test user for a second tenant and repeat step 2. Check database access, Guide visibility, and Dive metadata and source separately. A filtered listing alone is not proof of isolation.
6. Try calling an unexposed tool directly and reading another tenant's Dive by ID. Check SQL access to saved-object metadata too. These tests must meet your isolation policy before rollout.
7. Test two users within a tenant. Verify that personal preferences reach only the intended person.
8. Revoke access or rotate a token and verify that cached connections cannot retain unintended access.
9. Trigger a failed query and a truncated result. Confirm that the client receives the correct error or warning and that telemetry records the outcome.

## Troubleshooting

| Symptom | Likely cause | Fix |
|---|---|---|
| Agent output still mentions MotherDuck or Dives | A forwarded tool description or `next_steps` string still carries the upstream text, or `ask_docs_question` is exposed | Search your tool schemas and result rewrites for the terms. Remove `ask_docs_question` |
| `save_dive` returns `validationErrors` on code that follows your guide | Your replacement guide drifted from the upstream technical requirements | Diff against the current `get_dive_guide` output and update your baseline |
| A tenant can read another tenant's Dive metadata or source | Organization-wide Dive visibility or a missing authorization check on reads by ID | Check the underlying object permission boundary and every proxy read path. A service account per tenant and an owned-only listing do not make saved Dives private. |
| Queries time out at 55 seconds | Inherited `query` timeout | Add guidance to your `instructions` to aggregate rather than scan. Size the tenant's Duckling |
| Query results truncated | Inherited 2,048-row / 50,000-character cap | Same as above. Return aggregates, not row dumps |

## Inherited limits

- Result cap of **2,048 rows / 50,000 characters** and query timeout of **55 seconds**, per the [`query` reference](/sql-reference/mcp/core/query).
- Requests route to the MotherDuck MCP region nearest **your proxy**, and results transit through it. Run the proxy in your organization's region if you have data residency requirements. See [Regional availability](/sql-reference/mcp/#regional-availability).
- The proxy does not change feature availability or billing. Embedding Dives requires the Business plan. Check [MotherDuck pricing](https://motherduck.com/product/pricing/) and your organization's enabled features before exposing tools. Plan inclusion does not mean the queries and stored data have no usage cost.

## Related tasks

- [Connect to the MotherDuck MCP Server](/key-tasks/ai-and-motherduck/mcp-setup/)
- [Create and configure service accounts](/key-tasks/service-accounts-guide/create-and-configure-service-accounts/)
- [Embedding Dives in your web application](/key-tasks/dives/embedding-dives/)
- [Restricting to read-only access](/key-tasks/ai-and-motherduck/securing-read-only-access/)
- [Building analytics agents](/key-tasks/ai-and-motherduck/building-analytics-agents)
- [MotherDuck MCP server reference](/sql-reference/mcp/)


---

## Docs feedback

MotherDuck accepts optional user-submitted feedback about this page at `GET https://motherduck.com/docs/api/feedback/agent`.
For agents and automated tools, feedback submission should be user-confirmed before sending.

URL-encode query parameter values and send a GET request:

```text
GET https://motherduck.com/docs/api/feedback/agent?page_path=%2Fkey-tasks%2Fai-and-motherduck%2Fmcp-workflows%2Fwhite-label-mcp-server%2F&page_title=White-label%20the%20MotherDuck%20MCP%20server&text=<url-encoded user feedback, max 2000 characters>
```

Optionally append `&source=<url-encoded interface identifier>` such as `claude.ai` or `chatgpt`.

`page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": "<uuid>"}`, `400` for malformed query parameters, and `429` when rate-limited.