dagster-mono-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CF_ACCESS_CLIENT_ID | No | Cloudflare Access Client ID (required if the Dagster instance is behind Cloudflare Access). | |
| DAGSTER_GRAPHQL_URL | No | The Dagster GraphQL URL endpoint. | http://localhost:3000/graphql |
| CF_ACCESS_CLIENT_SECRET | No | Cloudflare Access Client Secret (required if the Dagster instance is behind Cloudflare Access). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dagsterC | Dagster runs & debugging. Actions: runs, run, logs, graphql, help {"action": "runs"} -> recent runs {"action": "runs", "status": "FAILURE"} -> failed runs {"action": "run", "id": "abc123"} -> run details {"action": "logs", "id": "abc123"} -> run logs {"action": "graphql", "query": "{ version }"} -> raw GraphQL {"action": "help"} -> full documentation |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
The single tool 'dagster' has clearly distinct actions (runs, run, logs, graphql, help) with no overlap in purpose. Each action targets a specific operation within the Dagster domain, making misselection impossible.
The tool naming is perfectly consistent as there is only one tool, 'dagster', and its actions follow a clear, uniform pattern (e.g., 'runs', 'run', 'logs') without any mixing of conventions or styles.
With only one tool, the server feels thin for a Dagster monitoring/debugging domain, as it bundles multiple distinct operations (e.g., querying runs, fetching logs, GraphQL) into a single tool. This may limit clarity and usability compared to a more granular tool set.
The tool covers core operations like retrieving runs, logs, and GraphQL queries, but lacks obvious lifecycle actions such as triggering new runs, pausing/resuming, or managing assets. This creates notable gaps for a full Dagster debugging workflow.