MCP server development

An MCP server is how you give an Assistant the ability to act in your systems. You write a server that exposes MCP tools, register it in DioscHub, and the Assistant calls those tools as the signed-in user — with the user’s auth forwarded to your server on each call, and any state-changing tool held behind an approval step until the user says yes.

DioscHub speaks standard Model Context Protocol. Your server does not import a DioscHub SDK or know anything about DioscHub. What this section documents is the thin contract on top of vanilla MCP that lets DioscHub discover your tools, forward identity to them, and gate the dangerous ones.

Start here

If you have not built one yet, the quickstart takes you from an empty file to an Assistant calling your tool in a few minutes:

Quickstart: your first MCP tool Write a two-tool server, register it, and watch the Assistant call it as the signed-in user.

The contract, one page at a time

Each of these is a self-contained part of the DioscHub MCP contract:

The DioscHub MCP contract Transport, tool naming, the fields DioscHub reads, and the response shape it expects.

Forward the user's auth to your server The BYOA header flow: how the signed-in user's credential reaches your tool, and why the model never sees it.

Gate state-changing tools behind Consensus Put an approval step in front of any tool that writes, so the user reviews it before it runs.

Read and write files from a tool Fetch a user's uploaded file or write one back — over a side channel, without the bytes passing through the model.

The TypeScript framework Optional: a package that implements this whole contract for you, so a TypeScript server is just tools plus one call.

Next: The DioscHub MCP contract.