Service credentials

A service credential is an OAuth2 client_credentials client that your organization owns. A headless client — an n8n workflow, a CI job, a server-side script — exchanges its client ID and secret for a short-lived access token and calls the gateway with that token. No browser, no interactive login, no static API key.

Reach for one when the client cannot complete an interactive OAuth login — it runs on a server with no browser — but can perform the token exchange itself: n8n's OAuth2 credential, most server SDKs, a CI script with a few lines of shell. If your client can launch a local command instead, the mcp-remote bridge is simpler — see Clients without OAuth.

Who can create one

• Creating and rotating require an organization admin on a Team or Company plan.
• Listing and revoking stay available to an org admin on any plan. That is deliberate: an organization that downgrades must still be able to kill a credential that is live.
• The credential belongs to the organization, not to the admin who created it — any of the organization's admins can see it and revoke it, and can rotate it while the organization is on Team or Company.
• It takes a seat of its own, counted together with people. The account page reads N of M seats used (people and service credentials). Your own sign-in counts as one of those seats, so an organization on a single seat adds a second before it can mint a credential. Seats and roles are covered in Manage your organization.

Create one

1. Open your account area → Service credentials and choose Create credential.
2. Name it after the system that will use it — n8n production, nightly CI. The name is how you will know what breaks when you revoke it.
3. Copy the client ID and the client secret into the secret store that client already uses.

Connect with it

Exchange the credential for an access token at auth.ansvar.eu, then send that token to the gateway as a bearer token:

# 1. Exchange the credential for an access token
TOKEN=$(curl -s -X POST https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token \
  -d grant_type=client_credentials \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET | jq -r .access_token)

# 2. Call the MCP endpoint with that token
curl -s -X POST https://gateway.ansvar.eu/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Access tokens last 15 minutes. The credential itself is long-lived, so the client should exchange the secret for a fresh token whenever the current one is close to expiry, and never write an access token to disk or into a saved configuration. Clients that speak OAuth2 client credentials natively — n8n's HTTP Request credential, most server SDKs — handle that refresh once you give them the token URL, the client ID and the secret.

Connect an agent to it

The steps above get you a token and prove the connection. What consumes that token is your own agent — the gateway is a tool source, not a model, so something on your side has to run the model and its tool loop. Two shapes, depending on how much you want to own.

Let your model provider connect for you

If you build on the Anthropic API, its MCP connector takes a remote server URL and a bearer token and runs the tool calls for you — you never write a tool loop. Pass the access token from step 1 as authorization_token:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 4096,
    "mcp_servers": [{
      "type": "url",
      "url": "https://gateway.ansvar.eu/mcp",
      "name": "ansvar",
      "authorization_token": "'"$TOKEN"'"
    }],
    "tools": [{"type": "mcp_toolset", "mcp_server_name": "ansvar"}],
    "messages": [{"role": "user",
      "content": "Using Ansvar: search EU law for the NIS2 incident reporting deadline. Cite the article."}]
  }'

The response carries mcp_tool_use and mcp_tool_result blocks alongside the text, so you can see which corpora answered and check the citations.

Or run the loop yourself

Any model can use the gateway if you drive the loop: call tools/list as above, hand those schemas to your model as its tool definitions, and when it asks for a tool, call tools/call and feed the result back. This is what an n8n workflow or a CI script is doing under the hood, and it is the route to take when your provider has no MCP support of its own.

What it can and cannot do

A service credential gets the same tool surface as a signed-in seat on your plan: search across the corpora, provision lookup, citation validation, workflow runs, document upload and report generation. It passes the same tier gates as any other seat and draws from the organization's pooled quota.

• Run ceiling — each credential carries a monthly workflow-run ceiling. The default is half of what one seat contributes to your organization's monthly pool, so one runaway agent cannot drain what the rest of the organization shares.
• Stays with signed-in humans — audit-ledger decryption, and assent on architecture proposals (a credential can propose changes; a person approves them). The gateway enforces this on both sides of the call: those tools are hidden from tools/list and refused at tools/call even if the client asks for one by name.

Standard seats

A credential can hold a seat of a licensed ISO standard, and that is how you build an agent that reads the standard rather than paraphrasing it from memory. Your organization buys seats of a standard; an admin then assigns each seat, under Standards & documents in the account area, to a person or to a credential.

The recipe for an ISO-expert agent is two things: a service credential, and a standard seat assigned to it. The two requirements are separate. A standard seat does not require an organization seat — a person can hold a standard on any plan. A credential does require Team or Company, because that is what creating a credential requires, so an agent that holds a standard is always inside a Team or Company organization.

Seats are per holder, not per organization: assigning a standard to one credential does not give it to the others. Releasing a seat returns it to the pool to assign again, and revoking a credential releases any seat it held. Volume discounts on seats are available on request — the pricing page has the contact route.

Rotate and revoke

Rotate issues a new secret and keeps the same client ID. The old secret stops working immediately, so update the client in the same change window. Rotate on a schedule you set, and straight away if a secret may have been exposed.

Revoke refuses new tokens immediately and frees the seat. Access tokens already issued keep working until they expire — up to 15 minutes. Plan for that window: revocation is not a kill switch for a request already in flight.

A row marked needs attention means the credential does not work — the client behind it cannot get a token. Revoke it and create a new one; there is nothing to repair in place.

Troubleshooting

• 401 right after a rotation — the client is still sending the old secret. The old one dies the moment the new one is issued; there is no overlap period.
• 401 on a token that worked minutes ago — the access token expired. Exchange the secret for a fresh one instead of storing the token.
• 404 at the endpoint — the MCP endpoint is https://gateway.ansvar.eu/mcp, not the bare host.
• Create refused, "all your seats are in use" — a credential takes a seat like a member does. Raise the seat count under Manage subscription, or revoke a credential you no longer need.
• Create or rotate refused on your plan — minting is Team and Company only. Listing and revoking still work, so an existing credential can always be shut off.
• A tool you expected is missing from tools/list — a credential sees the tool surface of its plan's tier, so check the tier gate for that tool first. The two admin-side surfaces (audit-ledger decryption, assent on architecture proposals) are hidden from credentials by design; run those from a signed-in seat.