StudioX MCP Simulators

Nothing to configure. Start here — if this fails, the problem is the network or the server URL, not a credential.

Auth mode

None

200 with a server timestamp.

A static key in a header of the API's choosing. The most common enterprise mode after bearer.

Auth mode

I have an API key or token

Header name

X-API-Key

Value

sim-api-key-4d9e21

200, and authenticated_as is null — a key identifies the application, not a person.

Send the right key under the wrong header name. The 401 names the header it wanted and the credential-looking headers that arrived, so you can tell a naming mistake from a wrong key.

The same key, in the URL instead of a header. Older APIs, and it behaves differently.

Auth mode

None — put the key in the tool URL

URL

https://mcp-simulators.studiox-ai.com/api/querykey?api_key=sim-api-key-4d9e21

200.

The key ends up in access logs, browser history and any Referer sent onward. That is the trade-off of this mode, not a defect — worth seeing once before choosing it.

A token you paste, sent as Authorization: Bearer on every call. No refresh, ever.

Auth mode

I have an API key or token → Bearer

Token

any token minted by /oauth/token or /login/*

200 naming whoever the pasted token belongs to.

A pasted token expires silently. When it does, every tool on the server starts failing at once with no change on your side.

Username and password on every request. It does carry an identity — but a stored one, the same for everybody using the server.

Auth mode

Basic Auth

Username / password

alice / alice (or bob, carol)

200 naming alice.

Everyone who uses this server is alice, whoever they actually are. That is the distinction from per-user sign-in.

Two or more fixed headers — a credential split across headers, or a key plus a tenant or account header.

Auth mode

Custom Headers

X-Client-Id

sim-client-42

X-Client-Secret

sim-secret-c7f1

200 listing both headers as verified.

Send only one. The error names which is missing rather than a bare 401.

The token alone is not enough — a second header says what kind of token it is. This is the Snowflake SQL API shape.

Auth

any bearer from /oauth/token or /login/*

Extra header

X-Sim-Token-Type: OAUTH

200 echoing the token type.

Omit the header. The 401 mentions the token, so the failure looks like a rejected credential — which is exactly how this goes wrong in real templates that forget to bake the header in.

The server fetches and refreshes its own token. One token, shared by everyone who uses the server.

Auth mode

The API logs me in for a token → OAuth

Token URL

https://mcp-simulators.studiox-ai.com/oauth/token

Client ID

studiox-sim-client

Client secret

sim-secret-8f2a

Grant

client_credentials

whoami returns "Shared Service Account" with is_shared_service_account true, and orders returns all 9 rows.

Credentials work in either a Basic header or the request body. The response reports which arrived as sim_credentials_via — use it to check what the client actually did rather than what the form says.

Right client, right secret, wrong scope. The token is genuine and still refused.

Token URL

https://mcp-simulators.studiox-ai.com/oauth/token

Scope

orders.read

200 with the granted scopes listed.

Ask for a token with no scope, or a different one. You get 403 — not 401 — and the body says the credentials were fine and only the scope was wrong. Without that distinction this failure reads as a bad secret.

Username and password to a login endpoint, a token back, bearer afterwards. Exensio-shaped, and common in enterprise estates.

Auth mode

The API logs me in for a token → Log in for a token

Login URL

https://mcp-simulators.studiox-ai.com/login/nested

Body fields

username=alice, password=alice

Token path

data.token

whoami names alice; orders returns 3 EMEA rows.

Five response shapes at /login/{token, access_token, nested, session, xauth} carry the same token under different key names. Try nested even if your API is simpler — a client that only reads top-level keys breaks there, and the symptom looks like bad credentials.

The token goes in X-Auth-Token, raw. Two separate fields differ from their defaults at once.

Login URL

https://mcp-simulators.studiox-ai.com/login/xauth

Token path

token

Header name

X-Auth-Token

Token prefix

(empty)

200 naming the user.

Leave the prefix as "Bearer " and it fails on purpose, saying so. A client that hardcodes the prefix cannot talk to this class of API at all.

Rejects any token issued more than 15 seconds ago, so the refresh path runs on demand instead of once an hour.

Auth

OAuth client credentials, as above

200 immediately after getting a token; 401 with token_age_seconds once it passes 15. A client that refreshes on 401 recovers by itself.

A client that caches its token and never refreshes fails here permanently. That is the bug this endpoint exists to surface.

Every user connects their own account. Calls run as them, with their permissions — not as a shared credential.

Register as

External MCP server: https://mcp-simulators.studiox-ai.com/mcp

Auth mode

OAuth — each user signs in

Sign-in URL

https://mcp-simulators.studiox-ai.com/oauth/authorize

Token URL

https://mcp-simulators.studiox-ai.com/oauth/token

Client ID / secret

studiox-sim-client / sim-secret-8f2a

Redirect URI

anything — nothing needs registering here

Sign in as alice, call list_orders, get 3 rows. As bob, 3 different rows. As carol, all 9.

9 rows while signed in as alice means the call fell back to the shared credential. It still returns 200 — the row count is the only signal.