list_workspace_vaultsLABSCO SUMMARY
The generated tools are a starting point, not a finished integration.
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.
What it is
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.
What you get
- 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
toolsdirectory and can be edited to match the credentials and endpoints you actually use - Multi-workspace configuration through per-workspace environment variables
Requirements
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.
Setup effort
Build from source — git clone https://github.com/ma3u/dust-mcp-server-postman-railway.git
USE CASES
Talking to a Dust agent from an MCP client
Connect once and let the server handle the session and conversation rather than the client.
Keeping a multi-turn exchange coherent
Messages route into a conversation that holds its state until the session expires.
Finding out which agents a workspace has
List the agent configurations, refreshing them when a new one was just added.
Deploying it somewhere your team can reach
Follow the Railway deployment guide with the same environment variables you used locally.
18 tools
Listed in project docs. Your client may show a different list.
list_assistantslist_data_source_viewsget_conversation_eventsget_data_sourcessearch_assistants_by_nameget_conversationretrieve_documentget_app_runget_events_for_messageupsert_documentget_documentscreate_conversationcreate_messagecreate_content_fragmentcreate_app_runsearch_data_sourcesearch_data_source_viewBEFORE YOU INSTALL
What to know first
Tools you get
18 tools named in the project's documentation.
Requires
- Node.js v18 or later
- DUST_API_KEY in your environment
- DUST_WORKSPACE_ID in your environment
- DUST_AGENT_ID in your environment
INSTALLATION
Connect your client
You clone and build this one yourself.
Server setup
git clone https://github.com/ma3u/dust-mcp-server-postman-railway.git
cd dust-mcp-server-postman-railway
npm install
cp .env.example .env
npm run build
npm startMCP Clients
Claude Desktop
{
"mcpServers": {
"<YOUR_SERVER_NAME>": {
"command": "<YOUR_ABSOLUTE_PATH_TO_NODE>",
"args": [
"<YOUR_ABSOLUTE_PATH_TO_MCP_SERVER>"
]
}
}
}mcpServer.js sits at the top of your clone: run realpath mcpServer.js there for <YOUR_ABSOLUTE_PATH_TO_MCP_SERVER>, and which node for <YOUR_ABSOLUTE_PATH_TO_NODE> (Node 18 or later — an older node has no fetch and tool calls fail). <YOUR_SERVER_NAME> is any name you choose, such as dust. Restart Claude Desktop afterwards.
Claude Desktop — Docker
In your clone of the repository (with .env filled in), build the image:
docker build -t <YOUR_SERVER_NAME> .{
"mcpServers": {
"<YOUR_SERVER_NAME>": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--env-file=.env",
"<YOUR_SERVER_NAME>"
]
}
}
}Both <YOUR_SERVER_NAME> values are the tag you built, and .env in --env-file=.env has to be the absolute path to your .env file — Claude Desktop does not start docker from the repository folder, so the relative path is not found.