People and invitations

Admin lives under Settings → Admin, on four tabs: People — the roster, the invitations you have sent and anyone waiting for access — plus Configuration, Health, and a Log of every administrative change.

​

The three roles

An admin can only act on members — not on the owner, not on themselves, and not on another admin. That restriction is what keeps the admin area from being a route to taking over an instance, and it holds everywhere. Creating new admins is narrower, and not quite uniformly so: So an admin connected over MCP can promote a member to admin, where the same admin cannot do it in the browser. If that matters on your instance, keep admin accounts to people you would let hold the owner’s own connection URL.

​

Inviting someone

Admin → People → Invitations → type an email → Send invite. They get a link, pick a password, and land in their own empty workspace. Links stay valid for 14 days. What is still outstanding is listed under the form, with a link to copy and a control to revoke. Email is optional. Until Resend is configured, creating an invite gives you a link to send however you like — nothing is blocked on it. By conversation:

Invite priya@example.com and write me the message to send her.

That is onboard_teammate: it checks whether email is configured and says so plainly if not, creates the invitation, hands you the accept URL in full when no email went out, and drafts the message to send. admin_list_invites shows what is outstanding with links and expiry. admin_revoke_invite cancels one so its link stops working.

​

When somebody cannot get in

Start with admin_user_detail, or click their name in Admin. One page carries when they joined, who invited them, whether that invitation email actually left, when they last signed in, which assistants they have connected and when each last called, whether they are being billed, how much they have built, every administrative change made to their account, and anything the instance recorded against their address — a bounced invite, a tool call that threw. That one page tells you whether the problem is the account or the email, which decides what you do next. There is no route from it into their brain, resumes or applications.

​

Resetting a password

admin_reset_user_password generates a new one and returns it once, so you can pass it on. Every session they had is ended, so an old browser stays logged out. It cannot be used on the owner, and an admin cannot reset another admin’s password. The reset is written to the audit log; the password itself never is.

​

Suspending and deleting

admin_set_user_active with isActive: false signs the person out everywhere and blocks both their login and their MCP connections immediately. Their data is kept. Setting it back to true restores everything. admin_delete_user is permanent and removes the account with everything it owns — brain, resumes, applications. Confirm before calling it.

​

The audit log

Admin → Log, or admin_audit_log. Newest first: invitations, role changes, suspensions, deletions, password resets, billing links, and changes to the instance’s own configuration — each with who did it, to whom, and when. Rows survive the deletion of the account they describe, so “who suspended this person” is still answerable afterwards. Narrow it by group — accounts, invites, passwords, billing, settings — and by search, which matches either side of a row: the admin who acted, or the account acted on. Page with offset; default 100 entries, maximum 500. Nothing in it touches anyone’s brain, resumes or applications, and a secret is recorded as having been set, never as its value.

Who changed the Resend key?

​

Per-workspace usage

admin_instance_stats gives the shape of the instance: how many people, how many active, how many invitations outstanding, and how much material exists across all accounts. Aggregate counts only — never another person’s content.