Creating application users

This page is an outline. What is here is accurate, but it is not yet the whole story — each section ends with a note on what is still to be written. For anything it does not answer, DEPLOYMENT.md and USING-MCP.md in the repository are the complete references.

A browser signs in with a form; an MCP client cannot. Accounts therefore carry API tokens, and the access matrix decides which configs each account may drive.

Issuing a token

On the Users page, issue the account a token. It is shown exactly once — only a BCrypt hash is stored — and it takes the form Bearer <id>.<secret>.

{ "headers": { "Authorization": "Bearer <id>.<secret>" } }

A token alone is not access

A new account starts with no grants. Tick the configs it may drive on the Access grid. The two are separate on purpose: the token says who, the grid says what.

You see	It means
401	No token, or a stale or revoked one
403	Signed in, but not granted that config
503	Nothing is serving that config — start it on the Runtime page
429	Over a per-caller rate limit; `Retry-After` says how long

Authorization is per config, not per tool

The grid decides which configs an account may drive. It does not map roles to individual tools at run time, and that is a design decision rather than a gap: an object left out of a config has no code generated for it at all, so enforcement by absence is stronger than a rule in a running process.

Two teams needing different tools over one schema is two configs. That also narrows what each account can reach, since configs are the unit of both curation and access.

The first admin

The account named by ADMIN_USERNAME cannot be deleted or demoted, even once other admins exist — it is the way back from a mistake in the access matrix. Other admins are ordinary in this respect.

To write. Resetting a password and the forced-change flow; revoking and rotating tokens; what the proxy records per call; OAuth 2.1 as the alternative for anything past a single trusted client.