Run a 30-minute proof-of-concept

You have read the model; now run it. This proof-of-concept gets the assistant acting as a signed-in user against a tool you control, in about half an hour. It is the evaluation reduced to its essential loop: embed → bind identity → register a tool → watch it act as the user.

You do not need production infrastructure for this. You need the DioscHub image running locally (or on a test host), an LLM provider API key, and a few minutes per step.

The four steps

1. Run DioscHub and open the admin portal. Start the published image with a database and your LLM provider key configured. The admin portal is where you create the Assistant for this test. See Install & run for the image and its configuration contract.

2. Embed the chat. Drop the diosc-chat web component into a page with your Assistant’s embed key and connect it. The embed quickstart is the copy-paste path, a few lines of frontend and a running widget.

3. Bind a sample identity (server-to-server). Wire the bind so the session carries a test user’s identity: the widget gives you a connection id, and a small backend endpoint calls DioscHub to bind a user and an auth artifact to it. For the proof-of-concept you can bind a fixed sample user; in production this is your real auth, and it never passes through the browser. The Identity & auth guide covers the bind endpoint contract. (To try the public model instead, skip the bind and start anonymous.)

4. Register a sample MCP tool. Stand up a minimal MCP server with one read tool and one state-changing tool, and register it against the Assistant. The MCP tool quickstart walks the whole tool, including how the forwarded auth reaches your server.

What to watch for

When you ask the assistant to do something that calls your state-changing tool, three things should happen:

• The assistant proposes the action and pauses for approval rather than acting silently.
• On approval, the tool runs and your MCP server receives the bound user’s auth; confirm it in your server’s own logs (not DioscHub’s). The assistant acted as that user.
• The language model never received the credential; it proposed the call from the conversation alone, and the auth was bound server-to-server, outside its view.

If you see those three, you have verified the core of the model against your own code. From here:

• Developers continue in Get started and Build.
• Operators continue in Operate; start with the production hardening checklist.
• Security reviewers continue in Secure & Comply.

That is the end of the evaluation trunk. You now know what DioscHub is, why it exists, where it sits, what it guarantees at the boundary, and how to prove it for yourself.