Chainlit offers a ready chat UI and public access by default, without an agent-builder platform. It still needs Python code for the model/tool loop and fixed MCP connections; its documented MCP UI lets visitors supply connections, not a locked public-bot configuration.

Chainlit: a small coded chat application, not a no-code bot appliance

Reviewed September 29, 2026. Documentation review only; no deployment was performed.

Chainlit authentication documents public access by default. The Python quickstart supplies a chat UI and a message callback in an application file, launched with chainlit run app.py. This is a materially narrower application shape than adopting an agent-builder platform.

The MCP guide supports SSE, Streamable HTTP, and stdio, but requires application handlers and integration with the model/tool loop. Its built-in connection interface accepts connection details from the visitor. That is different from the desired experience of an operator-configured public assistant. I propose configuring approved MCP endpoints in server-side application code or the chosen runtime, rather than exposing that connection interface to anonymous visitors. In particular, do not expose user-selected subprocess commands.

User sessions provide per-chat in-memory state. For a small initial deployment, I would keep only the active conversation and avoid adding a persistence service until needed. This is a proposed scope, not an Operator commitment.

Important limitation: the built-in chat-history feature requires authentication as well as persistence. Public conversation access does not automatically provide anonymous cross-session history.

Chainlit saves frontend and chat-server work, not all application code. Fixed MCP wiring, model execution, and public-use limits remain integration responsibilities. No memory, throughput, or isolation benchmark has been run.