Set Authorization: Bearer <access_token> on requests to
. Re-mint after 24 hours.
Clients
Steps and the example prompt below use the selected server.
Try asking: “”
Recommended: add the connector from claude.ai in your browser, not the
Desktop app. Desktop opens your OS's default browser to sign in - if a different Claude
account is already logged in there, it'll force you to switch accounts to finish connecting.
Settings > Connectors (Team/Enterprise: an owner adds it under
Organization settings first).
+ → Add custom connector.
Name the connector, and for the URL use .
Choose how the connector's Client ID / Secret is set:
Fill in Client ID / Secret under Advanced
That one credential becomes fixed for everyone using this connector - no individual
sign-in step, but everyone shares the same CDL account and entitlements as whoever's
credentials were entered. Works for both MCP servers.
Leave Advanced blank
Each person signs in individually with their own Client ID / Secret the first time they
use the connector. Different people on the same org connector can each use a different
CDL account - everyone sees only what their own credentials are entitled to.
Add → Connect → sign in with your credentials.
Try asking: “”
The Claude Code CLI. Works with either method.
Or skip the manual command - paste this prompt into Claude Code:
Method A (sign-in)
claude mcp add --transport http
Claude Code opens a browser sign-in the first time it uses a tool from the server.
Method B (bearer token)
claude mcp add --transport http \
--header "Authorization: Bearer YOUR_TOKEN"
Try asking: “”
Method A. Requires Developer Mode on a paid plan.
Enable Developer Mode.
Settings > Connectors > Create.
Enter , set Authentication to OAuth.
Save and complete sign-in.
HTTPS remote endpoints only. If the connector offers Bearer instead of OAuth, use method B.
Try asking: “”
Add the server to an mcp.json file - project-level (.cursor/mcp.json) or global (~/.cursor/mcp.json).
Or skip editing the file - paste this prompt into Cursor's chat:
Method A (sign-in)
{
"mcpServers": {
"": {
"url": ""
}
}
}
Cursor discovers the sign-in page automatically and opens it in your browser the first time a tool is used - no Client ID/Secret needed in the file.
OAuth yes → method A sign-in. OAuth no → paste a bearer token from the curl example (refresh
every 24h).
Try asking: “”
Use MCP Client Tool with Bearer auth (method B).
Add the node and wire it to your AI Agent.
Endpoint , Transport HTTP Streamable.
Authentication → Bearer; paste a token from the curl example.
Fetch tools, pick which to expose, save.
Try asking: “”
Use the MCP Client app (either the “Call a tool” or “Execute an action with AI” module).
Add an MCP Client module to your scenario and create a new connection.
Choose + new MCP server and paste .
If Make detects OAuth support it prompts a sign-in (method A). Otherwise, a credential field
appears below the URL - paste a bearer token from the curl example (method B).
For any other MCP-compatible client, or a custom integration you're building yourself.
OAuth-capable clients (method A)
Our servers support standard OAuth 2.1 discovery (RFC 8414) and dynamic client registration
(RFC 7591). Point a compliant client at the URL below with no credentials in the config - it will
discover the sign-in page on its own, the same way Claude and Cursor do:
{
"mcpServers": {
"": {
"url": ""
}
}
}
Header / bearer-token clients (method B)
If your client can only send a static header, mint a token with the curl example above and set it directly:
Not every client uses this exact JSON shape - treat it as a reference for the two required pieces: the MCP URL, and (if needed) the bearer header.
Troubleshooting
Symptom
Likely cause
I connected to the MCP but now get a 401
Method B token expired (24h). Re-mint with curl.
"Credentials were not accepted"
Typo in Client ID/Secret, or secret was rotated.
"This sign-in page has expired"
Form timed out (10 min). Restart from the client.
Got an unsupported_grant_type error
Your integration sent a token request straight to the MCP sign-in URL, which only handles
the browser sign-in flow (method A). For direct token requests, use method B's curl example
instead - it posts to our identity provider's token endpoint, not the sign-in page.