The session and conversation layer is the substantive part here and it is what makes multi-turn work with a Dust agent hold together. The tool files, though, are generated from a Postman collection, and the README says outright that they may need editing to use the right environment variables for authentication — expect that as the first task rather than a surprise. Deployment is the easy half: the Railway path is documented and the variable set is small.
A TypeScript MCP server that fronts the Dust API. It manages sessions and conversations itself — creating a session, routing messages into a conversation and holding the state between turns — so a client talks to a Dust agent through one connection instead of reassembling that flow each time. The tools that call Dust are generated from a Postman collection into a `tools` directory you can edit.
- Session management with a lifecycle of its own: a session is created, kept active, and expires on a TTL you configure
- Conversation state held across turns, so a multi-message exchange with a Dust agent stays coherent
- Workspace agent discovery over HTTP — the agent configurations for a workspace, or one specific agent by ID, with a force-refresh option
- A health endpoint for checking the server is up
- File upload support with a configurable size limit and upload directory
- Generated tool files you own: they live in the `tools` directory and can be edited to match the credentials and endpoints you actually use
- Multi-workspace configuration through per-workspace environment variables
Node.js v18 or later, with v20 or later recommended. `npm install`, then a `.env` carrying the Dust credentials — `DUST_API_KEY` and `DUST_WORKSPACE_ID` are required, `DUST_AGENT_ID` selects the agent. Optional settings cover `PORT`, `SESSION_SECRET`, `SESSION_TTL`, `MAX_FILE_SIZE`, `UPLOAD_DIR`, `STORAGE_PATH` and `LOG_LEVEL`. Deployment to Railway is documented, and the same variables apply there.