MCP gateway
DioscHub is an MCP gateway. Everything the assistant does in your systems passes through it: when the LLM decides to call a tool, DioscHub discovers that tool, forwards the signed-in user’s auth to the MCP server that owns it, and holds any state-changing call behind an approval step until the user says yes. Your servers stay plain Model Context Protocol — they never import a DioscHub SDK or know it exists.
This page is a map, not a lesson. Everything it links already lives in the Build and Operate pillars; this threads it into one subsystem view for when you’re thinking “the MCP gateway” rather than “I’m building” or “I’m operating.”
Build a server
Section titled “Build a server”Start here if you’re writing the thing the gateway talks to.
Forward identity through the gateway
Section titled “Forward identity through the gateway”How the signed-in user’s credential reaches your tool — and why the model never sees it.
Gate what it can do
Section titled “Gate what it can do”The gateway is where dangerous calls are held for a human, and where files cross without the model seeing them.
Register & operate it
Section titled “Register & operate it”Wire the server into an assistant, then watch it run.
The terms above — MCP server, MCP instance, MCP tool, Toolset, conduit — are each defined once in the glossary.