Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Origin Studio MCP Server

The server speaks Streamable HTTP and implements the MCP authorization specification, so any spec-compliant MCP client can discover how to authenticate without out-of-band configuration.

Endpoints

https://mcp-api.studio.fabricdata.com

The MCP endpoint is the root path. POST, GET, and DELETE on / all carry MCP traffic — there is no /mcp or /v1 suffix.

Two unauthenticated operational endpoints are available:

Path
Returns

GET /health

{"status":"ok"}

GET /info

Server name, version, and whether OAuth is enabled

Authentication

The server accepts Authorization: Bearer <token> in two modes.

Mode
Use it for
Token

User OAuth

Interactive agents acting as a signed-in Studio user

Auth0 JWT, obtained via the flow below

API key

Unattended jobs and service integrations

Long-lived Origin Studio API key

The MCP server is its own authorization server

This is the single most important thing to get right when integrating.

Origin Studio brokers login with Auth0 internally, using a first-party application that carries each tenant's enterprise connection. Clients never talk to Auth0 directly. All OAuth traffic goes to the MCP server's own endpoints, which it publishes in its discovery document.

Point your client at the MCP endpoint and let it discover the rest:

GET https://mcp-api.studio.fabricdata.com/.well-known/oauth-authorization-server

Protected-resource metadata (RFC 9728) is served alongside it at /.well-known/oauth-protected-resource, and an unauthenticated request to the MCP endpoint returns a standards-compliant challenge:

Do not hard-code Auth0 URLs

Auth0 issuer, authorization, and token URLs are an internal implementation detail. They differ per environment, and tokens obtained directly from Auth0 will not carry the tenant context the MCP server expects.

Client registration

Clients register at the MCP server's own registration_endpoint (/register), as published in the discovery document above. Spec-compliant MCP clients do this automatically — you do not need to configure anything.

Auth0's registration endpoint is not part of this flow

Dynamic client registration is disabled on Fabric's Auth0 tenants, and https://<auth0-tenant>/oidc/register will reject you. That endpoint is not the MCP server's registration endpoint and was never the right target. Always take the registration URL from the discovery document.

Agent platforms and integration partners should additionally go through partner onboarding to receive a durable, reviewed client rather than relying on self-registration.

User OAuth flow

Standard OAuth 2.0 Authorization Code with PKCE. PKCE is mandatory and only S256 is accepted; requests without code_challenge, or using plain, are rejected.

  1. Client redirects the user to /authorize with client_id, redirect_uri, code_challenge, code_challenge_method=S256, and state.

  2. The server redirects the user's browser to Auth0 to sign in.

  3. Auth0 returns to the server's /callback, which redirects back to your redirect_uri with an authorization code.

  4. Client exchanges that code plus its code_verifier at /token for an access token.

Clients are public clients — token_endpoint_auth_method is none. There is no client secret; PKCE binds the exchange.

Organization selection

Studio users belong to one or more organizations, and organization selection is required at login. Users are prompted to choose after authenticating. A client cannot pre-select the organization on the user's behalf, so users who belong to more than one tenant must pick the right one during sign-in.

Refresh tokens

Request the offline_access scope to receive a refresh token. Exchange it at /token with grant_type=refresh_token.

Handle with care

Refresh tokens are long-lived and non-rotating — the same refresh token remains valid across exchanges. They represent a user's standing delegated access to their tenant. Store them encrypted at rest, scope access to them tightly, and revoke on user offboarding.

API keys

For unattended workloads, pass an Origin Studio API key as the bearer token. The server accepts any non-JWT bearer as an API key and validates it server-side. API keys are issued per tenant from the Studio admin UI or the create_api_key tool, and carry the permissions of the identity they were created under.

API keys are the supported mechanism for headless and service-to-service access. There is no Auth0 client-credentials path for third-party integrations.

Connecting a client

Claude Code

No headers needed. Claude Code reads the discovery document, runs the OAuth flow in your browser, and stores the resulting tokens.

Claude Desktop and other MCP clients

Add the MCP endpoint as a remote HTTP (Streamable HTTP) server. Any client implementing MCP authorization will discover /authorize and /token automatically.

API-key clients

Clients that don't run an OAuth flow send the key as a bearer header:

Browser-based clients

The MCP endpoint applies DNS-rebinding protection: requests carrying an Origin header must present an allowlisted origin, or the server returns 403. Server-side integrations send no Origin header and are unaffected. If you are connecting from a browser context, ask your Fabric account team to allowlist your origin.

Integration partners

If you build a product that other companies use — an agent platform, a workflow tool, a media application — your customers may already be Origin Studio tenants. Partner onboarding lets them connect their own Studio account to your product.

What this unlocks

Your users work with their Origin Studio metadata inside your product, as themselves. That means:

  • No data export. Metadata is read live from Studio, so nothing goes stale and no copy has to be kept in sync.

  • No shared service account. Each user connects individually, so their actions are attributable to them and their access ends when their Studio access does.

  • No per-customer engineering. One integration works for every Studio tenant that signs in — you don't build or configure anything per customer.

  • Permissions come along. Each user's Studio role and permission groups apply automatically, so your product can't widen what someone is allowed to see or change.

For the tenant, the appeal is the same in reverse: they get their metadata where their work already happens, without handing anyone a credential that outlives the relationship.

Getting set up

Contact your Fabric account team to start. The process issues you a pre-registered OAuth client.

What you provide:

  • Partner and product name, as it should appear to users

  • Your redirect URI(s) — HTTPS, exact-match

  • A technical contact for security notifications

What you receive:

  • A client_id scoped to your redirect URIs

  • A named point of contact for integration support through launch

How it works at runtime

Each of your users signs in once through the flow above and selects their Studio tenant. You store that user's tokens and refresh them as needed. Every subsequent call is made with that user's token.

This model supports many users concurrently: each token carries its own identity, and the server derives tenant and permissions from the token on every call. One user's token can never reach another user's tenant.

Redirect URIs are exact-match. Wildcards and paths that differ from the registered value are rejected at /authorize. Send us any new URI before you deploy it.

Tenant scoping and permissions

Tenant is inferred from the token. Do not pass a tenant identifier to tools; no tool accepts one unless its schema explicitly requires it, and Studio ignores client-supplied tenant hints.

Authorization is enforced server-side on every call against the identity in the token, using the same permission model as the Studio web application. An agent can never exceed the permissions of the user or API key it is acting as. Tool-level access follows the identity's Studio role and permission groups, so two users connecting the same agent may see different results from the same tool.

Begin every session with whoami to confirm the active identity, tenant, and effective permissions.

Working with the tools

Tools are discoverable at runtime via tools/list, and each carries its own input schema and usage guidance. Reference catalogs — record fields, datasets, layouts, lifecycle definitions — are exposed as MCP resources via resources/list.

A few conventions worth knowing:

  • find_* tools are always safe to retry. They are read-only and have no side effects.

  • For writes, re-query before retrying. If a write times out, check whether it landed before sending it again.

  • Resolve keys before writing. Metadata fields and dataset values are tenant-specific; fetch the valid keys rather than guessing.

  • Lifecycle changes use lifecycle transitions, not metadata updates. Read the record's available transitions, then apply one.

  • File imports upload client-side. The server issues a presigned URL; your client uploads the file directly. File contents never pass through the agent.

Troubleshooting

Symptom
Cause

401 with a WWW-Authenticate header

No token, or an expired one. Refresh, or re-run the OAuth flow.

403 Origin not allowed

Browser-based client sending a non-allowlisted Origin. Contact your account team.

invalid_client at /authorize

Unknown or expired client_id. Re-register, or use the client issued to you.

redirect_uri does not match

The URI must exactly match a registered value.

DCR rejected at /oidc/register

You are calling Auth0, not the MCP server. Use the registration_endpoint from the discovery document.

HTML returned instead of JSON

You are not talking to the MCP server — check the hostname against the table above.

See also

Last updated