Prerequisites

What you need before creating your first connection. Most of it depends on which identity model you pick — Identity Brokering needs almost nothing, Tenant Delegated needs the most.

For every connection

RequirementDetail
A LockMCP workspaceCreated for you, with an invite sent to your admin email. See Getting Your Workspace.
An API with a base URLReachable over HTTPS from the internet. This is what your tools will call.
Credentials for that APIHowever LockMCP should authenticate to it — an API key, bearer token, or OAuth client. Stored encrypted.
Control of a domainYou'll prove ownership in Step 2 via a DNS TXT record or a file served at a well-known path. This gates provisioning for every identity model.
An OpenAPI specFor your API, so tools can be generated. See Writing OpenAPI Specs. You can add this after the connection is live.

Domain verification — decide the method now

You'll need one of these, so it's worth knowing which before you start:

MethodYou need
DNS TXT recordAccess to your domain's DNS settings. Allow time for propagation — minutes to hours.
Well-known fileThe ability to serve a file at a specific path on your domain, returning the raw token with a 200.

Pick whichever you can action faster. DNS is usually easier for a domain you own outright; the file method is often quicker if you control the web server but not the DNS.

Additional, by identity model

Identity Brokering

Nothing further. Step 3 of the wizard asks for nothing at all.

You will want a list of who should have access, so you can invite them once the connection is live.

Token Exchange

RequirementDetail
An OIDC identity providerOkta, Auth0, Entra ID, Keycloak, or your own.
Its JWKS URIe.g. https://auth.acme.com/.well-known/jwks.json
Its Issuer URIe.g. https://auth.acme.com
Public reachabilityLockMCP fetches your JWKS from its own servers. An IdP behind a VPN or IP allowlist won't work.

Both values come from your provider's discovery document at https://<your-idp>/.well-known/openid-configuration. See Token Exchange Configuration.

Token Exchange connections don't work with Claude Desktop, ChatGPT connectors or Cursor. If your users need those, choose a different model — see Choosing an Identity Model.

Tenant Delegated

The most substantial prerequisites, because your backend implements a contract.

RequirementDetail
A user directoryAny way of authenticating users — email/password, SSO, whatever you already run.
A login pageServed at a URL you control, accepting the hub's parameters. See Login Page.
Exchange and Validate endpointsServer-to-server, HMAC-signed. Refresh and Logout are optional.
All endpoints on HTTPSPlain HTTP is rejected during certification.
Validate responds within 5 secondsIt's called on tool requests, so it's on the hot path. Certification fails above this.
Ability to deploy the HMAC keyThe wizard generates it; your app must hold the matching value.

Your endpoints must pass a seven-check certification suite before the connection will provision — including that Exchange rejects unknown codes with a 4xx and Validate returns { "valid": false } for unknown tokens. Build against the Contract Specification, which is the normative reference.

Budget real engineering time for this one. The other two models are configuration; this is an integration.

A quick readiness check

Before opening the wizard:

  • [ ] I can sign in to the LockMCP dashboard
  • [ ] I know my API's base URL and have credentials for it
  • [ ] I can add a DNS TXT record or serve a file at a well-known path
  • [ ] I've picked an identity model — decision guide
  • [ ] (Token Exchange) I have my JWKS URI and Issuer URI
  • [ ] (Tenant Delegated) My login page and endpoints are deployed and publicly reachable
  • [ ] I have an OpenAPI spec, or know where to get one

Where to go next