dagster-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.10.0
Disambiguation5/5
Each tool targets a distinct resource and action—runs have five clearly differentiated tools (list, status, logs, stats, failure summary), and assets have search, details, health, and materialization history. Descriptions explicitly cross-reference when to use which tool, eliminating ambiguity.
Naming Consistency5/5
All tools use snake_case with a consistent verb_noun pattern ('list_*' for enumeration, 'get_*' for retrieval). Naming is uniform across code locations, runs, assets, jobs, schedules, sensors, and backfills.
Tool Count4/5
At 17 tools, this is slightly above the ideal 3-15 range but each tool fills a distinct monitoring need. The count is justified by the breadth of Dagster concepts covered, though it edges into 'heavy' territory.
Completeness2/5
The tool surface is entirely read-only—there is no way to launch a run, trigger a job, start/stop schedules or sensors, or update assets. Critical operational actions are missing, which will cause agent failures in real orchestration workflows.
Average 4.3/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return format and a parameter (limit) but does not address mutability, side effects, or permissions. The tool is likely read-only, but this is not explicitly confirmed, and no contradictions exist.
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 very concise with two short paragraphs and a bullet. It is front-loaded, no redundant sentences, and every line adds value. Structure is easy to scan.
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?
Given the output schema exists (covering return values) and the sibling list is provided, the description covers the core purpose and usage context. The omission of the 'env' parameter is a minor gap, but overall adequate for a monitoring tool.
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 description coverage is 0%, so the description must compensate. It explains the 'limit' parameter (max backfills, default 10), adding value beyond the schema's type and default. However, the 'env' parameter is not described, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'recent asset backfills', and specifies the returned information (status, partition progress, etc.). This distinguishes it from siblings like list_jobs which list different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section explicitly stating 'to monitor in-progress backfills or review recent ones', providing clear context. It does not mention when not to use or alternatives, but the guidance is direct and sufficient for the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses a key behavior: 'Raises when a code location is unavailable rather than returning a partial list that could be mistaken for the complete set of schedules.' However, it does not explicitly state that the operation is read-only (though listing implies it) and does not mention how the 'env' parameter affects results, which is a behavioral gap.
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 well-structured: it front-loads the purpose, lists output fields, gives usage context, names an alternative, and ends with an error behavior note. Every sentence serves a purpose; there is no fluff. It is slightly longer than necessary but the structure makes it easy to parse.
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?
The description covers the tool's main purpose, usage, and an error condition. It also lists return fields, which is helpful even though the output schema exists. However, it omits any explanation of the 'env' parameter, which is a significant gap for a tool with only one parameter. Additionally, it does not mention pagination or result limits, but that may be covered by the output schema. Overall, the description is incomplete because the sole parameter is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'env', with 0% description coverage, and the description never mentions 'env'. An agent is left without any indication of what 'env' does or how to use it (e.g., environment filter, context selector). Since the schema only provides type information (string or null), the description completely fails to add meaning to the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all schedules with their status, cron expression, target job, and next tick.' It specifies the resource (schedules) and the action (list) and enumerates key output fields. This distinguishes it from sibling tools like list_sensors or list_jobs, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'to check which schedules are active, verify cron timing, or find schedules that are stopped and might need attention.' It also tells the agent when to use an alternative: 'If a schedule is RUNNING but jobs aren't executing, use get_tick_history to inspect recent ticks for errors.' This is a clear routing decision with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It explains the meaning of key return fields like rootRunId and parentRunId for re-execution chains, and implies this is a read-only operation. However, it does not explicitly state that the tool has no side effects or discuss authentication needs, which would elevate transparency.
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 well-structured, starting with a clear purpose sentence, then listing returned fields, explaining key fields, and ending with usage guidance. It is concise but could be slightly shorter without losing meaning. Overall, efficiently communicates essential information.
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?
Given the tool has two parameters and an output schema, the description covers the main use case and explains return field semantics. However, it omits description of the env parameter, which is a gap. The mention of output fields is helpful but not essential since an output schema exists. Completeness is adequate but not thorough.
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%, so the description should compensate. It mentions run_id implicitly but does not describe the env parameter or provide format/usage details for run_id. This leaves the agent uncertain about what to pass for env (e.g., allowed values) and whether run_id is a UUID or name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details for a single run, including status, config, tags, and lineage. It distinguishes itself from sibling tools like get_runs (which lists runs) and get_run_logs/get_run_stats by focusing on a specific run and its lineage details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'When to use: after get_runs to inspect a specific run, or to check whether a run is a re-execution of a previous one.' This provides clear context for when the tool is appropriate and implies alternatives (e.g., get_runs for listing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It explains return fields (tick_id, status, etc.) and optional disambiguation parameters. Lacks disclosure on safety (read-only?), auth needs, or rate limits.
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?
Well-structured with bullet points and sections. Front-loaded with purpose. Slightly verbose but each sentence adds value.
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?
Output schema exists; description covers return values. Differentiates well among 16 siblings. Adequate for a tool with moderate complexity.
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?
Schema coverage is 0%, but description explains 5 of 6 parameters: instigator_name, instigator_type, limit, repository_name, location_name. Missing 'env' parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets tick history for schedules or sensors, with a specific verb and resource. It distinguishes from siblings like list_schedules/list_sensors by focusing on history rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'When to use' section with common patterns (e.g., all ticks skipped, failures). Provides actionable guidance but does not explicitly say when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'Raises when a code location is unavailable rather than returning a partial list.' It also states the return contents precisely. Slight gap: no mention of auth or rate limits, but these are contextually less critical for a read tool.
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 efficiently front-loaded with the core purpose, then dives into return fields, usage context, and failure behavior. Each sentence earns its place, and the structure is clear without redundancy.
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?
For a list tool, the description covers the main aspects: return fields, usage scenario, and failure mode. However, the undocumented 'env' parameter is a significant gap that leaves the tool incompletely specified. The output schema exists but the parameter semantics are missing, so completeness is not full.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'env' has 0% schema description coverage, and the description never mentions it. The agent has no idea what 'env' controls (e.g., environment name for code location resolution). The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: 'List all sensors with their status and target jobs.' It clearly distinguishes from siblings like list_schedules and list_jobs by focusing on sensors and their runtime details, plus the failure behavior. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When to use' clause: to check active sensors and triggered jobs. It also gives a conditional alternative: if a sensor is RUNNING but not producing runs, use get_tick_history to inspect ticks. This routes the agent correctly and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: read-only, does not filter external/observable/non-executable/partitioned matches, and returns asset_keys plus summaries. No contradictions.
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?
Description is moderately long but well-structured with clear bullet points listing syntax options. All information is relevant, though some details on output format could be condensed. No fluff.
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?
Given the complexity of syntax resolution and existing output schema, the description covers input syntax, output format, and read-only nature. Missing env parameter documentation slightly reduces completeness, but core functionality is well-described.
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 description must compensate. It thoroughly explains the asset_selection syntax (key predicates, wildcards, operators), but completely omits the env parameter. While the primary parameter is well-covered, ignoring a parameter reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resolves asset-selection syntax into concrete assets without launching a run. The verb 'resolve' and specific resource 'asset-selection syntax' distinguish it from sibling tools like list_jobs or get_asset_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates the tool is for resolving selection syntax for use with materialize_assets or backfill_assets, and states it is read-only. Provides clear context but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on. The description correctly implies a read-only operation via 'get', and details the return structure, but does not explicitly state that it performs no side effects or require specific permissions. Additional behavioral traits like pagination or rate limits are not addressed.
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 well-structured with a clear purpose statement, followed by return field details, parameter descriptions, and usage guidance. Each sentence adds value with no redundancy. It is front-loaded and concise.
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 description is comprehensive for a read-only list tool: purpose, return structure, two parameters, and usage guidance. However, it omits the env parameter and does not explain how the tool relates to other sibling tools like get_asset_details. The existence of an output schema reduces the need for extensive return value documentation, but the missing env param is a notable gap.
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?
The description covers two of three parameters (asset_key with example, limit with default), but omits the env parameter entirely. Since schema coverage is 0%, the description must compensate, but the omission of env is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement: 'Get the most recent materializations for an asset, with metadata.' It further specifies the fields returned, distinguishing the tool from the sibling get_asset_health which is for broader health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section that lists specific use cases (check last materialization, track frequency, inspect metadata) and explicitly recommends get_asset_health for a broader view, providing clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return structure in detail (healthy, daemons, queued_runs_count, queued_runs_count_capped, code_location_errors) and explains the meaning of 'healthy' and the cap condition. It implies a read-only operation but does not explicitly state side effects, permissions, or error cases beyond code location errors. This is strong but not exhaustive, hence a 4.
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 well structured: a one-sentence purpose with emphasis ('START HERE'), a clear bulleted list of return fields with explanations, and a dedicated 'When to use' paragraph. It front-loads the key message and wastes no words. Every sentence adds value, and the length is justified by the detailed return spec.
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 return values are fully explained (healthy logic, daemon list shape, queued runs count and cap, code location errors), and follow-up tools are suggested. There is an output schema present, which likely covers the return types, so the description doesn't need to repeat that. However, the env parameter is unexplained, and there is no mention of how to handle unreachable instances or authentication. These gaps reduce completeness slightly.
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 tool has one parameter (env) with zero schema description coverage (0%). The description never mentions env, its purpose, or expected values. This is a gap: an agent cannot correctly set this parameter based on the description alone. While the parameter is optional, the lack of any guidance is a notable omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific purpose: 'Get a global health check of the Dagster instance.' It defines the resource (instance) and the action (get health check), and explicitly positions itself as the first step in monitoring workflows. It distinguishes itself from siblings by framing its global scope and hinting at follow-ups with list_code_locations or get_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'as the FIRST call in any diagnostic or monitoring flow.' It also gives conditional logic: if healthy=false, check daemons and code_location_errors, and suggests follow-up tools. This is clear, actionable guidance that tells the agent exactly when to invoke it and what to do next.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully describes the behavior: it returns consolidated failure info, lists the exact fields returned, includes an edge case ('If the run did not fail, returns {message: 'Run did not fail.'}'), and mentions automated diagnostic hints. It does not cover authentication or rate limits, but these are not critical for this query tool.
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 concise and well-structured. It opens with a clear purpose statement, then provides usage guidance, lists return fields in a bulleted list, and ends with tool selection advice. Every sentence adds value without redundancy.
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?
Given the tool has an output schema, the description sufficiently explains the return values, including edge cases. However, the lack of parameter description slightly reduces completeness. Overall, it provides rich context for an AI agent to understand the tool's function and output.
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%, so the description should explain the parameters (run_id and optional env). However, it only implicitly implies run_id by saying 'for a run' but provides no details about parameter format, required vs optional, or the meaning of env. The output schema is rich but the input parameters are not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a consolidated failure diagnosis for a run in a single call.' It distinguishes itself from sibling tools like get_run_status, get_run_logs, and get_run_stats by combining their outputs, making it the best choice for failed or canceled runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'always prefer this over get_run_logs for failed runs.' It also specifies when to use alternatives: 'Use get_run_logs only when you need the full event stream.' This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the return structure (runId, status, stepStats with fields) and implies a read-only operation. Could note lack of side effects, but overall sufficient.
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?
Concise, well-structured with bullet points summarizing return fields. Every sentence adds value; no fluff.
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?
Given output schema exists, description provides a useful summary. Could mention how to obtain run_id (from get_runs), but not critical. Covers essential aspects for a stats tool.
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%, yet the description does not explain the parameters 'env' or 'run_id' beyond their presence in the schema. No semantic guidance on formatting or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets per-step execution statistics for a run, listing specific data points (timing, materializations, expectations). Distinguishes from sibling tools like get_run_failure_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (find slow steps, check materializations, verify expectations) and when not to (for failed runs, prefer get_run_failure_summary), with alternative provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return values including error cases. However, it does not explicitly state read-only nature or mention any authentication/rate limits, but the scope is limited and safe.
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?
Concise three-sentence structure plus bullet-like return list. Every sentence adds value with no redundancy. Front-loaded with purpose, then returns, then usage guidance.
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?
Given an output schema, description does not need to detail return values. It covers usage, return fields, and error cases. Missing parameter documentation is a minor gap, but overall complete for its complexity.
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 has one optional parameter (env) with 0% documentation coverage. The description does not explain the parameter's purpose or effect, which is a significant gap for a simple list tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists code locations and their load status, with specific return fields. It differentiates from sibling tools like get_instance_status by mentioning when to use it after deployment or when errors occur.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section provides clear context for usage: after deployment to verify loading or when get_instance_status reports errors. Also suggests an alternative action (reload_code_location) for failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to carry safety or side-effect info, the description does a solid job: it details return event types, explains the level_filter ordering and special inclusion of failure events, and describes pagination via cursor. It could be more explicit that this is a read-only operation and doesn't mention rate limits, but these are minor omissions given the thoroughness.
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 well-structured with a lead summary, event details, a parameter list, and a usage note. It is front-loaded with the core purpose, and every sentence adds value—no filler or repetition. The organization makes it easy to scan.
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 description covers the main use case well, including return event structure, filtering behavior, and pagination. It points to a sibling for alternative usage. However, it does not mention the 'env' parameter, possible error conditions, or rate limits. Given the tool's complexity and the absence of annotations, these omissions leave some ambiguity, though not enough to prevent correct use.
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?
The description explains run_id, level_filter (with detailed semantics), cursor (pagination), and limit (default), but completely omits the 'env' parameter that appears in the schema. Since schema description coverage is 0%, this gap means the agent must guess the purpose of 'env'. The documented parameters are explained well, but the missing one prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'gets structured log events for a run' with optional filtering and pagination. It distinguishes itself from sibling tools by explicitly referencing get_run_failure_summary as the alternative for quick failure diagnosis, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section that tells the agent exactly when to prefer this tool ('full event stream or filter by level') versus the sibling get_run_failure_summary for consolidated failure info. This is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly lists returned fields (runId, status, jobName, etc.) and explains filtering parameters with valid values and examples. It does not mention pagination or ordering, but for a list operation, transparency is high.
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 well-structured with sections for returns, filtering, and typical workflows. It is somewhat verbose but every sentence adds value. The formatting aids readability. A slightly more concise version could still be effective, but it is not excessive.
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?
Given the tool's complexity (4 params, 0 required, output schema exists), the description covers the main parameters and usage patterns. It explains return fields and provides examples. It could mention default sorting or limit behavior, but overall it is complete for a list tool.
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?
Schema coverage is 0%, so the description must compensate. It explains job_name, statuses (with valid values and examples), and limit (default 10). However, the env parameter is not described, so coverage is incomplete. Overall, it adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List recent pipeline runs' and frames it as the starting point for discovery. It also distinguishes from sibling tools like get_run_status by indicating that get_runs is for initial listing and returns runIds for further drill-down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Start here to discover what has been running.' It offers typical workflows such as finding failures, checking job runs, and monitoring active runs. It also directs users to use the returned runId with other tools, effectively differentiating when to use each sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior for group matching, return structure, and staleness explanation. No annotations, but description covers key aspects. Could mention performance or error cases.
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?
Well-structured with clear sections, bullet points, and no fluff. Every sentence adds value.
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?
Covers essential return fields and usage, but could add notes on error handling or limitations. Output schema exists, so return value explanation is bonus.
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?
Main parameter asset_key_or_group is well-explained with examples and behavior. However, optional env parameter has no explanation despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a consolidated health view for assets, with explicit details on return fields and distinction from sibling get_recent_materializations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly includes 'When to use' section with concrete use cases and recommends preferring this over get_recent_materializations for health assessments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description details return fields, filter behavior (case-insensitive, combined), and default behavior when no filters. It is transparent about being a read-only discovery tool, though missing authentication or rate limit info.
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?
Well-structured with clear sections for filters, returns, and usage. Concise but could be slightly more streamlined. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers all needed aspects: purpose, filters, behavior, and when to use. It is complete for a search tool with no missing critical information.
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?
Schema coverage is 0%, but description explains prefix and group in detail (substring match, case-insensitive, combined). However, the 'env' parameter is not explained in the description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search and list assets by name prefix or group' with specific filter options. It clearly differentiates from sibling tools like get_asset_details and get_asset_health by stating it is for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' guidance: 'to discover available assets before calling get_asset_details or get_asset_health'. Also advises on filter choice: 'Use prefix for fuzzy search, group for scoped listing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It details the return fields: assetKey, description, groupName, op name, isObservable, isPartitioned, partitionDefinition, dependencyKeys, dependedByKeys, and latest materialization. This implies a read-only operation with no destructive effects. However, it does not explicitly state that the tool is read-only or mention any authorization requirements, which would have earned a 5.
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 concise and well-structured. It begins with a clear single-sentence summary, lists the return fields in a bullet-like format, and ends with usage guidance. Every sentence adds value without redundancy, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (2 parameters, 1 required) and an output schema (not shown but indicated). The description provides all necessary information: purpose, parameter details, comprehensive return fields, and usage context with sibling differentiation. There are no significant gaps given the available context signals.
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?
Schema description coverage is 0%, so the description must compensate. It explains the required 'asset_keys' parameter as 'list of asset name strings (e.g. ['my_extract', 'my_load'])', which adds meaning beyond the schema type. The optional 'env' parameter is not explained, but it is less critical as it has a default of null. The description adds value for the key parameter, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get detailed metadata for one or more assets: description, lineage, and partitions,' which clearly states the action (Get), resource (assets), and specific data fields (description, lineage, partitions). This distinguishes it from siblings like search_assets (used for finding assets by name) and get_asset_health (which focuses on health status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes 'When to use: to understand an asset's lineage... Use search_assets first if you don't know the exact key.' This provides clear guidance on appropriate use cases and directs users to an alternative tool when the asset key is unknown, which is highly helpful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden — and it delivers thoroughly. It discloses the raise-vs-empty behavior on broken/loading locations, the distinction between filtered and unfiltered calls, and the exact-match filter semantics. This is precisely the behavioral context an agent needs to avoid misinterpreting empty results.
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?
Well-structured: purpose and return value are front-loaded, followed by filter semantics, error behavior, and a closing when-to-use. Every sentence adds information; the only minor deduction is that the error-handling paragraph could be tightened slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a filtered-list tool with an output schema. The description covers purpose, filter semantics, error behavior, load-health redirection, and usage context. With an output schema present to document return fields, nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully: it explains that repository_name and location_name are independent exact-match filters, that both must match when supplied together, and that no-filters lists everything loaded. The env parameter is the only one not explicitly discussed, but its role is implied by the tool context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('jobs across code locations'), describes the return payload (repository name, code location name, job name, description), and differentiates itself from siblings like list_code_locations and launch_job. An agent can immediately tell what this tool does and how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('as a starting point to explore what jobs exist, or to find the exact job name and repository_location needed for launch_job'), and gives detailed context on filter behavior and the error-raising condition. It also directs the user to list_code_locations or get_instance_status for load-health checks, effectively routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dagster-mcp MCP server](https://glama.ai/mcp/servers/fabdendev/dagster-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fabdendev/dagster-mcp)

Score Badge

Copy to your README.md:

[![dagster-mcp MCP server](https://glama.ai/mcp/servers/fabdendev/dagster-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fabdendev/dagster-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fabdendev/dagster-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server