DBOS MCP Server
Official# DBOS MCP Server
This repository contains a Model Context Protocol (MCP) server with tools that can analyze and manage your DBOS workflows.
It enables LLMs to retrieve information on your applications' workflows and steps, for example to help you debug issues in development or production.
To use this server, your application should be connected to [Conductor](https://docs.dbos.dev/production/conductor).
You may want to use this alongside a DBOS prompt ([Python](https://docs.dbos.dev/python/prompting), [TypeScript](https://docs.dbos.dev/typescript/prompting), [Go](https://docs.dbos.dev/golang/prompting), [Java](https://docs.dbos.dev/java/prompting)) so your model has the most up-to-date information on DBOS.
## Setup
### Install `uv`
Before using this MCP server, you must install `uv`.
For installation instructions, see the [`uv` installation docs](https://docs.astral.sh/uv/getting-started/installation/).
### Setup with Claude Code
To use this MCP server with Claude Code, first install it:
```bash
claude mcp add dbos-conductor -- uvx dbos-mcp
```
Then start Claude Code and ask it questions about your DBOS apps!
Claude will prompt you to log in by clicking the URL it offers and authenticating in the browser.
Credentials are stored in `~/.dbos-mcp/credentials`.
## Tools
#### Application Introspection
- `list_applications` - List all applications
- `list_executors` - List connected executors for an application
#### Workflow Introspection
- `list_workflows` - List/filter workflows
- `get_workflow` - Get workflow details
- `list_steps` - Get execution steps for a workflow
#### Workflow Management
- `cancel_workflow` - Cancel a running workflow
- `resume_workflow` - Resume a pending or failed workflow
- `fork_workflow` - Fork a workflow from a specific step
#### Authentication
- `login` - Start login flow (returns URL to login page)
- `login_complete` - Complete login after authenticatingTDQS
Scored across 25 tools
Each tool targets a distinct resource-action pair, and the singular/bulk workflow tools follow a clear pattern. The closest potential confusions are fork_workflow vs. fork_from_failure and get_workflow_events vs. get_workflow_notifications, but the descriptions clearly separate batch vs. single and outbound vs. inbound.
All tool names use snake_case with a leading verb (list_, get_, cancel_, resume_, delete_, trigger_, pause_, etc.), and bulk variants follow the predictable bulk_<verb>_<resource>s convention. The only deviation is the login/login_complete pair, which is a clear sequential flow rather than an inconsistency.
At 25 tools, the server is on the high side, but the count is justified by the broad domain: auth, applications, workflows, steps, executors, schedules, and versions each need multiple operations. The bulk workflow variants add some redundancy, but they are conventional and useful for operational workflows.
Workflow coverage is strong: list, get, cancel, resume, fork, delete, aggregate, events, notifications, and steps are all present. The main gaps are the lack of create/update/delete operations for schedules and applications, but those resources appear to be registered by the application itself rather than managed through the MCP server.