Skip to content

Glossary

The reader-facing terms used across the documentation. The core concepts page shows how they relate.

A Session with no signed-in user, used for a public assistant. It runs a limited, guarded surface and is promoted in place when the visitor signs in.

See Consensus.

The configured AI entity a user talks to. It has one or more Roles and its own model configuration.

DioscHub runs no auth system of its own. Your backend supplies the user’s identity and auth artifact per connection, and DioscHub forwards it to your MCP servers.

The approval gate on a state-changing MCP tool. The assistant proposes the action and its parameters; the user approves, edits, or rejects; only an approved call runs.

The guarantee that a user’s auth artifact is never placed in the language model’s context. It is forwarded to your tools around the model, not through it.

The public credential your frontend puts in the page to load an Assistant. It identifies which Assistant to load, not who the user is.

Documents you load so the assistant can answer from your content. The assistant retrieves the relevant passages on demand.

The open protocol DioscHub uses to expose your systems’ tools to the language model.

A registered, configured MCP server inside DioscHub.

Your wrapper around a business system: a thin adapter over an existing API that exposes MCP tools. You write and host it.

One callable an MCP server exposes: the unit the assistant calls to read or change something.

A way of using an Assistant. It carries the tools, system prompt, model budget, and feature flags for that way of using it. Auth is not on the Role; it arrives per connection.

Binds one user to one Assistant, within a domain, for the life of a conversation. It carries the user’s identity, so the assistant acts as that user.

An admin-facing grouping of MCP tools that an admin assigns to Roles together.