Most memory servers give every client the same tools and trust the prompt to keep them apart. Here the token is the boundary: it can only narrow what its owner already has, administrative tools are hidden from access tokens entirely, and a personal document stays invisible even to someone who can read the storage it sits in. That matters once more than one agent, or more than one person, is pointed at the same store.
A gateway you run yourself. It stores knowledge items (text, uploaded files, fetched links) with embeddings and search, proxies upstream MCP servers behind the same endpoint, and hands out scoped tokens so tools/list returns a different toolset per caller.
- A dynamic tools/list: a research agent sees only knowledge_search, an authoring agent also sees the write tools
- Tokens that narrow rather than widen — the intersection of the owner's ACL and the token's own scopes
- Per-document visibility on top of storage access: personal, group or public
- admin_token_create, admin_token_list, admin_token_revoke and admin_token_update_scopes to run token lifecycle from the client
- admin_acl_grant, admin_acl_revoke, admin_storage_create and admin_storage_archive for access and storage changes
- admin_user_list, admin_group_members, admin_group_add_member and admin_group_remove_member for people and groups
- admin_mcp_server_list, admin_mcp_server_test and admin_mcp_scope_set to register upstream MCP servers and scope their tools
- A web admin console for users, groups, storages, tokens, item ingest, search and service status
Your own infrastructure: Postgres, Redis and S3 or MinIO, reached either through the bundled Docker Compose file or by running the Go binary directly (Go 1.23+). Clients connect over Streamable HTTP at /mcp with a bearer token; Claude Desktop connectors additionally need the server published on a public HTTPS host, because the OAuth flow cannot reach localhost.