Organizations, roles and namespaces
Organizations
Section titled “Organizations”An organization is your team’s account: it has members, namespaces and a plan. Every new account gets a personal organization; you can create more and belong to several. Switch between them under Organizations.
| Role | Can |
|---|---|
| Owner | everything, including the plan, billing, renaming, export and deletion, and making others owners |
| Admin | create and delete namespaces, create and revoke API keys, invite and remove members |
| Member | upload, edit and delete documents; see diagnostics and the key list |
An organization always keeps at least one owner. Invite people from Members; an invitation is a single-use link valid for 7 days, and it creates the account if the person doesn’t have one yet. They can accept with a password, or with Google or GitHub if that account’s email is the invited address.
Namespaces
Section titled “Namespaces”A namespace is the unit of isolation. Documents belong to exactly one namespace, and an API key reads and writes exactly one namespace — there is no way for a key to reach another namespace or another organization.
Typical layouts:
- one namespace per agent (
support-bot,sql-assistant), or - one per audience (
internal,customer-facing) with several agents sharing it.
A namespace also has a description (agents read it at the top of
get_toc) and a retrieval profile — focused for a handful to a few
dozen documents, catalog for hundreds of similar ones; see
How retrieval works. Admins set both on the
namespace page, where they also pin documents
every agent gets without asking.
API keys
Section titled “API keys”Keys look like imcp_…, are stored only as a hash, and can be revoked at any
time from the namespace’s API keys page. Create one key per consumer —
per agent, per environment — so revoking one doesn’t break the others.
Each key may make 600 requests per minute across MCP and the REST API; beyond
that, requests get 429 with a Retry-After header.