What can you do with this server?

This MCP server exposes read-only Dagster inspection capabilities through six tools. * Overview: repository/job list, last 10 runs, backfills, and active schedules. * Assets: list assets with code version, last materialization, and partition count; fetch one asset’s state/metadata by key. * Runs: list runs filtered by job/status; fetch run detail by run_id (status, tags, metadata, step states). * Automation: list sensors and schedules with their state. * Constraints: the provided schema does not expose write/materialization, raw GraphQL, backfill, workspace, or examples tools from the README.

Which integrations are available for this server?

Provides tools for querying a Dagster instance's GraphQL 1.x API, including specialized tools and raw read-only GraphQL queries for exploring workspaces, assets, partitions, lineage, runs, automations, and backfills.

How do I use mcp-dagster?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-dagster show me the latest dagster runs and any failed assets" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-dagster

by Aluriak

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mcp-dagster

Un MCP pour interroger l'API GraphQL 1.x d'une instance Dagster : workspace/code locations, assets, états de partitions, lineage, runs, automatisations (schedules/sensors), backfills.

Design V2 : le serveur privilégie la latitude de l'agent. Les outils spécialisés couvrent les questions courantes ; dagster_examples fournit des requêtes GraphQL modèles documentées que l'agent peut adapter, combiner et lancer via dagster_raw_query (accès au schéma complet). Toutes les requêtes embarquées sont validées contre le vrai schéma 1.12.1 (fixture tests/schema_1_12_1.graphql).

Lecture d'abord : en mode read_only (défaut), aucune opération d'écriture n'est autorisée — y compris une mutation transmise via dagster_raw_query. La seule écriture fournie est dagster_materialize, derrière read_only: false ET une confirmation explicite (read_only=false au niveau du tool).

Installation

python -m venv .venv
.venv/bin/pip install .        # ou : pip install ".[dev]"

Le point d'entrée s'appelle mcp-dagster (stdio, compatible n'importe quel client MCP : Claude, Hermes, …).

Related MCP server: graphql-introspection-mcp

Configuration

Deux façons, la dernière gagnant :

Fichier YAML — par défaut ./config.yaml, puis ~/.config/mcp-dagster/config.yaml, sinon le chemin de l'env DAGSTER_MCP_CONFIG :

base_url: "https://dagster.example.org"
api_token: ""            # Bearer ; ne pas mettre en clair (voir env)
forward_header: ""       # mode relay du jeton utilisateur (voir plus bas)
graphql_url: ""          # URL absolue du point d'entrée GraphQL (défaut : <base_url>/graphql)
timeout: 30
read_only: true          # défaut : tout write GraphQL refusé
extra_headers: {}

Variables d'env (recommandées pour le token) :

Variable	Champ
`DAGSTER_MCP_CONFIG`	chemin du fichier YAML
`DAGSTER_MCP_BASE_URL`	`base_url`
`DAGSTER_MCP_API_TOKEN`	`api_token`
`DAGSTER_MCP_FORWARD_HEADER`	`forward_header`
`DAGSTER_MCP_GRAPHQL_URL`	`graphql_url` (URL absolue du point d'entrée GraphQL)
`DAGSTER_MCP_TIMEOUT`	`timeout`
`DAGSTER_MCP_READ_ONLY`	`read_only` (`0`/`1`, `true`/`false`)
`DAGSTER_MCP_PORT`	port HTTP du serveur conteneur (défaut `8080`)

L'API est contactée par défaut sur <base_url>/graphql (layout standard d'une instance Dagster, l'UI est sur /). Si votre instance expose le point d'entrée ailleurs, définissez graphql_url (YAML) ou DAGSTER_MCP_GRAPHQL_URL (une URL absolue, ex. https://dagster.example.org/api).

Authentification derrière oauth2-proxy : si l'instance passe par oauth2-proxy + un IdP (Keycloak, …), il faut un token que le proxy accepte. Si le client OIDC côté proxy est confidential, le password grant headless échoue sans son client_secret — dans ce cas un token provisionné (Vault, variable CI, ou un client OAuth dédié public) est la voie la plus simple. Vérifiez la nature du client OIDC de votre proxy avant de brancher un token.

Relay du jeton utilisateur (`forward_header`) — mode HTTP partagé

En mode conteneur streamable-HTTP stateless, le serveur est partagé par tous les utilisateurs via un seul process. Un api_token statique figé au démarrage donnerait à tout le monde les mêmes droits Dagster, même pour celui que l'oauth2-proxy a déjà filtré en amont. Le serveur MCP ne doit jamais élargir les droits d'un utilisateur.

Solution : le serveur relaie, tel quel, le jeton de la requête MCP entrante au lieu d'utiliser un token figé.

# Mode relay (à la place de api_token)
base_url: "https://dagster.example.org"
forward_header: "Authorization"   # nom du header à relayer vers Dagster
# api_token doit rester vide / absent

Comportement :

Chaque requête MCP entrante doit porter le header configuré (ex. Authorization: Bearer <jeton de l'utilisateur>).
Sa valeur est relayée telle quelle comme Authorization sur l'appel GraphQL sortant (vers le point d'entrée configuré, par défaut <base_url>/graphql).
Si le header est absent ou vide : l'appel échoue explicitement côté MCP (message d'erreur clair). Aucun repli sur api_token.
Si api_token ET forward_header sont définis : erreur de démarrage (mutuellement exclusifs) — ne configurer qu'un des deux.
Le mode stdio (usage local, un seul utilisateur) garde api_token tel quel ; forward_header est conçu pour le mode HTTP partagé.

Exemple consommateur côté client MCP HTTP (pattern générique, sans nom de produit) :

# Config du client MCP HTTP qui consomme le serveur en mode partagé
mcpServers:
  dagster:
    url: "http://localhost:8080/mcp"
    headers:
      # Le client (ou le reverse proxy en amont) doit poser le jeton
      # de l'utilisateur courant dans le header nommé par forward_header.
      Authorization: "Bearer {{ current_user_token }}"

En pratique, c'est l'infrastructure en amont (oauth2-proxy, load balancer, client MCP) qui injecte le jeton de l'utilisateur courant dans ce header — pas le LLM. Le serveur n'y touche pas : il le relaye tel quel.

Outils (V2 — API Dagster 1.x)

Lecture :

Outil	Description
`dagster_overview`	locations + repositories, 10 derniers runs en erreur, backfills récents — point de départ
`dagster_workspace_status`	état détaillé des code locations (chargement, source de définitions, métadonnées)
`dagster_list_assets`	assets du repository : clé, groupe, jobs, stockage, partitions
`dagster_list_assets_paginated`	assets paginés (tous repos), filtrables par préfixe de clé
`dagster_asset_status`	état complet d'un asset : partitions, fraîcheur, ressources, lineage amont/aval, dernières matérialisations
`dagster_list_runs`	runs filtrables par job et/ou statut(s)
`dagster_run_detail`	détail d'un run : tags, config, stats par step, 60 premiers événements (logs, échecs, métadonnées de matérialisation)
`dagster_automations`	schedules + sensors : actif/désactivé, cron, prochain tick simulé, 5 derniers ticks
`dagster_backfills`	backfills en cours/terminés et leur progression par partition
`dagster_jobs`	jobs/pipelines du repository + partition sets

Latitude agent :

Outil	Description
`dagster_examples`	requêtes GraphQL modèles documentées (erreurs récentes, partitions du mois, queue, automatisations, locations, lineage, ressources↔assets, métadonnées de run) — à adapter puis lancer
`dagster_raw_query`	requête GraphQL arbitraire lecture seule en mode `read_only` (les mutations y sont refusées) ; accès au schéma complet en read-write

Écriture (read-write uniquement) :

Outil	Description
`dagster_materialize`	matérialise des assets (backfill) — verrou serveur `read_only: false` + confirmation explicite `read_only=false`

Si l'instance expose plusieurs repositories, les outils qui ciblent un repository acceptent location/repository (les valeurs sont visibles via dagster_overview) ; sinon le premier repository accessible est utilisé.

Exemple de déclaration (client MCP)

{
  "mcpServers": {
    "dagster": {
      "command": "/chemin/.venv/bin/mcp-dagster",
      "env": {
        "DAGSTER_MCP_BASE_URL": "https://dagster.example.org",
        "DAGSTER_MCP_API_TOKEN": "<token>",
        "DAGSTER_MCP_READ_ONLY": "1"
      }
    }
  }
}

Image conteneur

Réseau / header Host. Le port du SDK mcp 1.x vers FastMCP 3.x a supprimé à la racine l'ancienne protection anti-DNS-rebinding (contrôle du header Host) qui provoquait des 421 Misdirected Request derrière un réseau de conteneurs (le client envoie Host: <conteneur>:8080, pas un loopback). Le SDK 3.x n'applique aucun contrôle de Host par défaut — plus aucune configuration nécessaire ; un test de bout en bout le garantit (tests/test_http_host.py, Host: mcp-dagster-ro:8080). L'authentification réelle reste le relay du jeton utilisateur (voir ci-dessus).

Le conteneur expose le serveur en streamable-HTTP stateless sur le port DAGSTER_MCP_PORT (défaut 8080) :

python -m mcp_dagster

Construire et lancer :

podman build -t mcp-dagster:local -f Containerfile .
podman run --rm -p 8080:8080 \
  -e DAGSTER_MCP_BASE_URL=https://dagster.example.org \
  -e DAGSTER_MCP_API_TOKEN=*** \
  -e DAGSTER_MCP_READ_ONLY=true \
  mcp-dagster:local
# endpoint MCP : http://localhost:8080/mcp

Extrait de compose pour LibreChat (serveur MCP HTTP) :

services:
  mcp-dagster:
    image: ghcr.io/votre-org/mcp-dagster:latest
    environment:
      - DAGSTER_MCP_BASE_URL=https://dagster.example.org
      - DAGSTER_MCP_API_TOKEN=***          # via Vault, jamais en clair
      - DAGSTER_MCP_READ_ONLY=true
    restart: unless-stopped

L'image est publiée sur GHCR par la CI GitHub Actions (voir .github/workflows/ci.yml) : tag immuable par commit, plus latest sur la branche par défaut et par tag.

Tests

.venv/bin/python -m pytest tests/ -q

Tous les tests sont hors-réseau (client httpx mocké). Les 19 requêtes embarquées (outils + exemples) sont validées dans la suite contre le vrai schéma Dagster 1.12.1 (fixture tests/schema_1_12_1.graphql, généré via create_schema() de dagster-graphql) : tout dérive de schéma échoue les tests.

Convention de versionnage

La version du MCP = la version de Dagster visée (ex. tag v1.12.1 du repo ↔ webserver Dagster 1.12.1). Quand le support d'une autre version de Dagster sera ajouté (nouvelle fixture de schéma + validation), le tag suivant reflète la version visée.

Limites connues / suite

Les requêtes sont calées sur le schéma Dagster 1.12.1 ; sur des versions très différentes du webserver, un champ peut avoir bougé — dagster_raw_query (et les erreurs GraphQL remontées) restent le plan B.
dagster_materialize (backfill d'assets) est le seul outil d'écriture ; les autres écritures (terminer un run, recharger un repository, …) passent par dagster_raw_query en read-write, à l'initiative de l'opérateur.
Pas encore de streaming des logs de run en continu (les 60 premiers événements sont retournés par dagster_run_detail).

Licence

GPL-3.0-or-later — voir LICENSE.

Available Tools

6 tools

dagster_asset_stateC

État et métadonnées d'un asset (key = chemin, ex. "ch.dataset" ou "ch/dataset" ; le « . » est normalisé en « / »).

Name	Required	Description	Default
`key`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full disclosure burden, yet it only reveals one behavioral detail: that dots in the key are normalized to slashes. It never states that the operation is read-only, what 'state' comprises (materialization, freshness, partitions), or what happens for an unknown key.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with the purpose front-loaded followed by a parenthetical parameter hint; nothing is redundant. The nested quotes and guillemets are slightly awkward but do not obscure the content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and a one-parameter read tool does not need extensive prose. Still, with zero annotation coverage and no statement of what 'état' includes or how missing assets are handled, the description is only minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does provide a format, two concrete examples, and a normalization rule. However, it omits other basics such as case sensitivity, whether repository/location prefixes are accepted, or what a malformed key produces.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (an asset) and what it returns (state and metadata), which is specific enough to distinguish it from listing tools like dagster_list_assets or dagster_run_detail. It stops short of explicitly contrasting itself with those siblings, leaving the agent to infer the granularity difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus dagster_list_assets or dagster_overview, and no mention of preconditions such as the asset needing to exist. The only usage-oriented content is the key-format hint, which is input syntax rather than situational guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dagster_list_assetsB

Liste des assets Dagster avec leur code version, dernière matérialisation et nombre de partitions.

Name	Required	Description	Default
`page_size`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description must carry the behavioral burden. It implies a read-only listing and describes some returned fields, but it does not state read-only semantics, pagination behavior despite the page_size parameter, or any permission constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted words. The line break is cosmetic and does not hurt readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be exhaustively described. However, with no annotations and an undocumented page_size parameter, the description omits invocation details such as pagination behavior and read-only safety.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single optional parameter page_size has 0% schema description coverage, and the description does not mention pagination or explain what page_size controls. It adds essentially no parameter meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ("Liste") and resource ("assets Dagster") and even names the returned fields (code version, last materialization, partition count). It does not explicitly distinguish itself from siblings such as dagster_asset_state, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Listing assets is implied as the use case, but there is no explicit guidance on when to choose this tool versus dagster_asset_state or dagster_overview. No exclusions, prerequisites, or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dagster_list_runsB

Liste des runs (optionnel : filtre par job et/ou statut, ex. SUCCESS, FAILURE, RUNNING, CANCELLED).

Name	Required	Description	Default
`status`	No
`job_name`	No
`page_size`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It conveys that this is a listing operation, but it does not mention pagination, ordering, permissions, result limits, or other behavior around retrieval beyond the optional filters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with the core purpose front-loaded. It contains no redundant or wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has three parameters and no annotations, and although an output schema exists, the description omits page_size and does not explain pagination or filtering semantics beyond basic status examples. For a list tool with 0% schema description coverage, this leaves too much undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains filtering by job and status and gives example status values, but it does not mention the page_size parameter at all, leaving a significant semantic gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: listing runs, with optional filtering by job and/or status. It clearly distinguishes this from detail-oriented siblings such as dagster_run_detail, though it does not explicitly mention sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by 'Liste des runs' and the described optional filters. However, it provides no explicit when-to-use versus alternatives guidance, no exclusions, and no mention of when dagster_run_detail would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dagster_overviewB

Vue d'ensemble de l'instance Dagster : nom du dépôt, liste des jobs, 10 derniers runs, backfills et schedules actifs.

Name	Required	Description	Default
`page_size`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose the shape of the result set and a fixed cap of 10 runs, which implies a bounded read-only aggregate, but it never states that the call is read-only, how expensive it is, or how page_size interacts with the fixed run limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the scope first and then enumerates contents. No filler, though the enumeration style leaves no room for the usage or parameter context the definition needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out, and the description covers what is aggregated. However, with zero annotations and an undocumented parameter, an agent still lacks the read-only confirmation and the meaning of page_size needed to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the sole parameter (page_size, default 50) is never mentioned in the description, so an agent gets no guidance on what it paginates — the job list? the backfills? — especially given the text hard-codes '10 derniers runs'. The description leaves the only parameter fully opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (the Dagster instance) and enumerates exactly what the aggregate contains: repository name, jobs, last 10 runs, backfills, and active schedules. That makes it distinguishable from the narrower siblings (dagster_list_runs, dagster_sensors_schedules), though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the phrase 'Vue d'ensemble' — an agent can infer this is the cheap first call before drilling into dagster_run_detail or dagster_asset_state. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must reason about routing on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dagster_run_detailB

Détail d'un run Dagster (id du run) : statut, job, tags, métadonnées de run et état de chaque step.

Name	Required	Description	Default
`run_id`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries more burden. 'Détail' strongly implies a read-only lookup, and it lists returned content, but it does not explicitly state read-only behavior, error handling for invalid run ids, or permission requirements. Because an output schema exists, listing return fields is helpful context but not essential behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence that is front-loaded with the action and resource, then lists returned fields. It is efficiently sized for a simple detail tool, though the line break is slightly awkward.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description redundantly enumerates them. For a one-parameter read tool this is mostly adequate, but missing sibling routing and explicit read-only/error behavior leaves gaps given the absence of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the sole parameter. The description's parenthetical '(id du run)' reaffirms that run_id identifies the run, but it adds no format, constraints, or examples beyond what the parameter name already conveys. It minimally compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ('run Dagster') and operation ('détail') with the required identifier, and enumerates what detail is exposed (statut, job, tags, metadata, step states). It implicitly distinguishes itself from dagster_list_runs by being a detail lookup, though it does not name that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this tool is for retrieving one run once a run_id is known, likely after dagster_list_runs. There is no explicit statement of when to use this versus the sibling list/overview tools, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dagster_sensors_schedulesB

Sensors et schedules de l'instance avec leur état.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation by describing returned sensors and schedules with their state, but does not state that it is read-only, mention side effects, or describe pagination or authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no unnecessary detail. It is appropriately sized for a zero-parameter listing tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so the description need not explain return values, and the zero-parameter schema is simple. The description covers the resource and instance scope, but lacks usage context that would help an agent choose this over sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description does not create confusion about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ('Sensors et schedules') and adds scope ('de l'instance avec leur état'), so an agent knows it retrieves sensor and schedule metadata with state. It does not explicitly distinguish itself from sibling tools like dagster_overview or dagster_list_runs, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no when-to-use guidance, no exclusions, and does not name alternatives or contrast with sibling tools. The agent must infer that this is the tool for sensor/schedule state rather than, for example, dagster_overview.

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.

6 tool updatesv0.1.0Oct 28, 2026
- First observeddagster_asset_state
- First observeddagster_list_assets
- First observeddagster_list_runs
- First observeddagster_overview
- First observeddagster_run_detail
- First observeddagster_sensors_schedules

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.3/5.0

Scored 2026-10-28 22:25 across 6 tools

Disambiguation4/5

Each tool targets a distinct resource: instance summary, asset list, single asset state, run list, single run detail, and sensors/schedules. The only soft overlap is dagster_overview, which summarizes runs and schedules that dagster_list_runs and dagster_sensors_schedules also expose, but the descriptions make the summary-vs-detail distinction clear enough.

Naming Consistency4/5

All tools share the dagster_ prefix and snake_case, giving a predictable namespace. Most follow a verb_noun shape (list_assets, list_runs, run_detail, asset_state), with dagster_overview and dagster_sensors_schedules being minor deviations but still readable.

Tool Count5/5

Six tools is well-scoped for a Dagster observability surface, covering summary, assets, runs, and schedules without redundancy. Every tool earns its place and nothing feels like filler.

Completeness3/5

The surface is read-only: there is no way to launch or re-run a job, trigger a backfill (despite backfills being mentioned in the overview), or materialize an asset, and no run logs access. These are notable gaps for an agent trying to act on Dagster, though inspection workflows are well covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Caisy MCP by usefulapi
io.usefulapi
Run read-only GraphQL queries and list documents and media assets in Caisy.
Content Management Systems Databases
1
https://caisy.usefulapi.io/mcp
OpsLevelOAuth
com.opslevel
Query your OpsLevel internal developer portal: catalog, maturity data, and tech docs.
Developer Tools Documentation Access
2
https://app.opslevel.com/mcp
HoneycombOAuth
io.honeycomb
Query Honeycomb observability data: traces, events, metrics, SLOs, triggers, and boards.
Observability Monitoring
2
https://mcp.honeycomb.io/mcp
mcp A
com.googleapis.container
Provides read access to your GKE and Kubernetes resources.
Cloud Platforms Virtualization Monitoring
232
https://container.googleapis.com/mcp

Related MCP Servers

hasura-mcp-server
Databases Developer Tools
suryarajendhran
A
license
Not graded
quality
D
maintenance
Enables read-only interaction with Hasura GraphQL APIs, including table exploration, data preview, and schema introspection.
Updated 9 months ago (2026-01-28 08:17 UTC)
16 npm
MIT
graphql-introspection-mcp
API Testing Developer Tools Documentation Access
nano-step
A
license
A
quality
D
maintenance
Provides comprehensive GraphQL introspection, filtering, and query/mutation execution with safety controls. Enables AI agents to explore and interact with GraphQL APIs through natural language.
Updated 5 months ago (2026-05-19 16:20 UTC)
7
12 npm
1
MIT
graphql-mcp
API Testing Developer Tools
colofonbrigade
A
license
B
quality
D
maintenance
Exposes any GraphQL API as a single tool for executing queries and mutations with authentication support.
Updated 7 months ago (2026-04-07 23:40 UTC)
1
MIT
DuckDB MCP Server
Databases
poovenp
F
license
Not graded
quality
D
maintenance
Enables running read-only SQL queries and exploring DuckDB databases through MCP tools like listing tables, describing schemas, and fetching paginated data.
Updated 3 months ago (2026-08-07 06:37 UTC)
-

mcp-dagster

Installation

Configuration

Relay du jeton utilisateur (forward_header) — mode HTTP partagé

Outils (V2 — API Dagster 1.x)

Exemple de déclaration (client MCP)

Image conteneur

Tests

Convention de versionnage

Limites connues / suite

Licence

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Relay du jeton utilisateur (`forward_header`) — mode HTTP partagé