dagster-mono-mcp
dagster-mono-mcp
MCP-сервер с одним инструментом для Dagster. Один инструмент, пять действий, минимальные затраты токенов.
У Dagster есть официальный MCP-сервер, но мне не удалось легко заставить его работать. Это минималистичная альтернатива, которая охватывает действия, действительно необходимые при отладке конвейеров с помощью LLM: список запусков, просмотр деталей запуска, чтение логов и необработанный GraphQL для всего остального.
Поддерживает Cloudflare Access для экземпляров Dagster, находящихся за Zero Trust — простой и бесплатный способ защитить ваш экземпляр Dagster.
Установка
Claude Code
Для конкретного проекта (.mcp.json в корне вашего проекта):
{
"mcpServers": {
"dagster": {
"command": "npx",
"args": ["-y", "github:pjatx/dagster-mono-mcp"],
"env": {
"DAGSTER_GRAPHQL_URL": "https://dagster.example.com/graphql",
"CF_ACCESS_CLIENT_ID": "your-client-id",
"CF_ACCESS_CLIENT_SECRET": "your-client-secret"
}
}
}
}Глобально (~/.claude.json — доступно во всех проектах):
{
"mcpServers": {
"dagster": {
"command": "npx",
"args": ["-y", "github:pjatx/dagster-mono-mcp"],
"env": {
"DAGSTER_GRAPHQL_URL": "https://dagster.example.com/graphql"
}
}
}
}Cursor
Добавьте в .cursor/mcp.json в корне вашего проекта:
{
"mcpServers": {
"dagster": {
"command": "npx",
"args": ["-y", "github:pjatx/dagster-mono-mcp"],
"env": {
"DAGSTER_GRAPHQL_URL": "https://dagster.example.com/graphql",
"CF_ACCESS_CLIENT_ID": "your-client-id",
"CF_ACCESS_CLIENT_SECRET": "your-client-secret"
}
}
}
}Windsurf
Добавьте в ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"dagster": {
"command": "npx",
"args": ["-y", "github:pjatx/dagster-mono-mcp"],
"env": {
"DAGSTER_GRAPHQL_URL": "https://dagster.example.com/graphql",
"CF_ACCESS_CLIENT_ID": "your-client-id",
"CF_ACCESS_CLIENT_SECRET": "your-client-secret"
}
}
}
}Related MCP server: MCP Access OAuth Server
Переменные окружения
Переменная | По умолчанию | Обязательно |
|
| Нет |
| — | Нет (обязательно, если за CF Access) |
| — | Нет (обязательно, если за CF Access) |
Использование
Единый инструмент dagster с диспетчеризацией действий:
Список запусков
{"action": "runs"}
{"action": "runs", "status": "FAILURE"}
{"action": "runs", "job": "my_job", "limit": 5}Детали запуска
{"action": "run", "id": "<run-id>"}Логи событий
{"action": "logs", "id": "<run-id>"}
{"action": "logs", "id": "<run-id>", "limit": 100}Необработанный GraphQL
{"action": "graphql", "query": "{ version }"}
{"action": "graphql", "query": "query($id: ID!) { runOrError(runId: $id) { __typename } }", "variables": {"id": "abc123"}}Помощь
{"action": "help"}Возвращает полную документацию, включая доступные статусы, все параметры и примеры запросов.
Проектирование
Этот проект следует паттерну «моно-инструмента»: один MCP-инструмент с диспетчеризацией действий вместо множества мелких инструментов. Меньшее количество инструментов означает меньшие затраты токенов для LLM и более простой выбор инструмента — модели не нужно выбирать между дюжиной инструментов с похожими названиями. Вдохновлено публикацией Cloudflare Code Mode о переосмыслении того, как LLM взаимодействуют с MCP-серверами.
Разработка
npm install
npm run build # esbuild bundle -> dist/index.js
npm start # run the MCP server (stdio transport)Лицензия
MIT
Available Tools
1 tooldagsterC
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
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| id | No | ||
| job | No | ||
| status | No | ||
| limit | No | ||
| query | No | ||
| variables | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what each action does (e.g., 'recent runs', 'run details'), but lacks critical behavioral traits such as authentication requirements, rate limits, error handling, or whether actions are read-only or destructive. The examples imply read operations but don't explicitly state safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with a brief purpose statement followed by action examples. Each sentence earns its place by illustrating usage, though it could be more structured (e.g., bullet points) and the initial line is somewhat vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is incomplete. It covers actions and some parameters but misses details on return values, error cases, and full parameter semantics. Without annotations or output schema, more behavioral and contextual information is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains what each action does and provides example parameter combinations (e.g., 'runs' with 'status', 'run' with 'id'), clarifying how parameters interact. However, it doesn't cover all 7 parameters (e.g., 'job', 'limit', 'variables' are unexplained), so it doesn't fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'Dagster runs & debugging' and lists five actions, which gives a general purpose but lacks specificity about what Dagster is or what resources it operates on. It distinguishes between actions but doesn't clearly articulate the overall tool's function beyond listing sub-actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, as there are no sibling tools mentioned. It lists actions with examples but doesn't explain prerequisites, contexts, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
dagster
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.
Maintenance
Related MCP Connectors
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloudflare Workers MCP server: ai-cost-optimizer
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloudflare Workers MCP server: graphql-rest-bridge
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceA Cloudflare Workers-based MCP server that enables deployment of custom tools accessible via the Model Context Protocol without authentication requirements.-
- FlicenseNot gradedqualityCmaintenanceA Cloudflare Workers-based MCP server that enables secure remote connections using built-in OAuth authentication via Cloudflare Access. It provides identity-based access control for MCP tools and supports persistent state management through Durable Objects and SSE.-
- FlicenseNot gradedqualityDmaintenanceRemote MCP server with built-in OAuth authentication via Cloudflare Access, enabling secure tool invocation after user sign-in.-
- FlicenseNot gradedqualityCmaintenanceThis is an MCP server deployed on Cloudflare Workers with OAuth authentication, enabling remote MCP clients to connect and use tools.-