Authentication

The MCP server supports two authentication patterns:

Mode	Who it is for	Credentials
Interactive	Individual Language Weaver users	Auth0 access token sent as Authorization: Bearer ...
Service	Automation or shared integrations	Lw-Client-Id and Lw-Client-Secret

Interactive login

Use this when the client should act as the signed-in user. The MCP client obtains an Auth0 access token and sends it as a Bearer token on MCP requests.

The MCP server validates that token and then forwards it verbatim to the Language Weaver API — the same token authenticates both hops. This is token pass-through: no second token is issued and no identity is substituted, so the Language Weaver API sees the individual user, and the call has exactly the permissions, account, groups and roles that user has.

Service credentials

Use this when the client should act as a Language Weaver API client associated with an account.

Send these headers on each request:

Lw-Client-Id: <client-id>
Lw-Client-Secret: <client-secret>

The credentials are validated on every request and are used for the downstream Language Weaver calls, so different clients are authenticated and attributed distinctly.

If both are supplied, service credentials take precedence: when Lw-Client-Id and Lw-Client-Secret are present and valid, the request runs as that API client and an accompanying Bearer token is ignored.

Choosing a pattern

Both patterns are accepted on the same endpoint, so you can configure an interactive entry, a service entry, or both side by side. Pick per entry:

• Interactive when the translations should be attributed to, and limited to, the person using the client.
• Service for automation, shared integrations, or anything running unattended, where no one is present to complete a browser login.

If authentication fails, the server rejects the request before any tool runs and the response tells your client what to do next — see Connection-level errors.