dagster-mcp

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation5/5
Every tool has a clearly distinct purpose: listing jobs, fetching runs, inspecting run details/logs/stats/failures, managing assets, searching, checking health, schedules, sensors, backfills. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_jobs, get_run_status, search_assets, get_instance_status). No mixing of conventions or vague verbs.
Tool Count5/5
17 tools cover the essential monitoring and diagnostic capabilities for Dagster (jobs, runs, assets, schedules, sensors, backfills, instance health). This is well-scoped—not too few for a complex orchestrator, not overwhelming.
Completeness4/5
The set comprehensively covers read operations for monitoring and debugging: listing, status, logs, failure analysis, asset health, schedule/sensor tick history. However, it lacks write operations (e.g., launching jobs, materializing assets) which are mentioned in descriptions but not implemented, leaving a minor gap for full lifecycle management.
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on July 27, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It does not disclose any behavioral traits such as pagination, rate limits, or safety guarantees. A simple 'List all jobs' implies read-only, but no explicit confirmation.
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?
Three sentences, front-loaded with the core action, then return details, then usage guidance. Every sentence adds value with no fluff.
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?
Covers the return fields and usage, but lacks details about the optional 'env' parameter, potential filtering, or limits. With an output schema present, the return structure is partially covered, but missing information reduces completeness.
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?
Schema has one optional parameter 'env' with 0% coverage. The description does not mention this parameter at all, failing to compensate for the missing schema details.
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 all jobs across all code locations, with a specific verb 'List' and resource 'jobs'. It distinguishes from siblings like get_runs by noting it returns job metadata needed for launch_job.
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.' This provides clear usage context and even references a sibling tool.
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 are provided, so the description carries the full burden. It states it lists schedules and returns specific fields, but does not explain the behavior of the optional 'env' parameter or any constraints like pagination or rate limits. Some ambiguity remains about the parameter's effect.
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 with clear sections: what it does, what it returns, and when to use. No wasted words.
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 tool is simple with one optional parameter and an output schema present. The description covers purpose, return fields, and usage guidance, referencing a sibling tool. However, it omits explanation of the 'env' parameter, which is a minor gap in completeness.
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 no description in the input schema (0% coverage) and the description does not mention it at all. Users must guess its purpose and how it affects the results, which is a major 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 uses specific verb 'List' and resource 'schedules', clearly stating it lists all schedules with their status and other fields. It distinguishes from sibling 'get_tick_history' by mentioning a different use case.
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 specific contexts: checking active schedules, verifying cron timing, finding stopped schedules. It also directs to an alternative tool 'get_tick_history' for cases where schedules are running but jobs aren't executing.
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 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, the description carries the full burden. It accurately describes the tool as a read-only list operation and specifies return fields. However, it does not explain the effect of the optional env parameter or any potential filtering, which is a minor 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?
Three sentences, no redundancy, front-loaded with key information. Every sentence adds value: purpose, return fields, usage guidance, and an alternative. Excellent conciseness.
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 purpose, return fields, and usage guidance, and an output schema exists. However, the unexplained env parameter is a notable omission, and no mention is made of pagination or result limits. For a simple list tool, this is adequate but incomplete.
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?
Schema description coverage is 0%, so the description must compensate. It fails to mention the single optional parameter 'env' at all. The agent receives no guidance on what env does or how to use it, leaving a critical gap for a listed 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?
Description clearly states the tool lists all sensors with status and target jobs, and explicitly differentiates from get_tick_history for the troubleshooting case. The verb 'List' and resource 'sensors' are specific and distinct from sibling tools like list_jobs or list_schedules, earning top marks.
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' section and gives a conditional alternative: if a sensor is RUNNING but not producing runs, use get_tick_history. This clearly guides the agent on when to use this tool versus alternatives, exceeding the minimum.
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, 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?
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the return structure: healthy boolean, daemons list with fields, queued_runs_count with interpretation, and code_location_errors. Explains health condition (all daemons healthy AND no errors).
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 and well-structured: one-line purpose, bulleted return fields, and explicit when-to-use guidance. Every sentence adds value, with no 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?
Despite lacking parameter documentation, the description thoroughly explains the tool's output and usage patterns. With an output schema present (per context), the return format is well covered. Missing env description is a minor gap.
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 only parameter 'env' is not mentioned in the description. Schema coverage is 0%, and the description adds no meaning beyond the schema's type and default. The description fails to explain its purpose or impact.
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 defines the tool as retrieving a global health check of the Dagster instance. States 'START HERE for any monitoring workflow,' distinguishing it from sibling tools that focus on specific jobs, runs, or assets.
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 the FIRST call in any diagnostic or monitoring flow.' Provides follow-up steps if healthy=false, guiding the agent to check daemons and code_location_errors.
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?
No annotations provided, so description carries full burden. It details return structure (field names, event types), pagination (cursor), filtering behavior, and special case for level_filter=ERROR (includes failure events). 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?
The description is well-structured with sections (parameters, when to use) and avoids fluff. It is slightly long but every sentence adds value. Could be slightly tightened.
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 doesn't need to fully detail return values but does so helpfully. It covers event types and fields. However, it omits the 'env' parameter, which is a small gap. Overall adequate for the complexity.
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 explain parameters. It explains run_id, level_filter (values and special behavior), cursor, and limit default. However, the 'env' parameter is missing from the description entirely, leaving it 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 tool's purpose: 'Get structured log events for a run, with optional severity filtering and pagination.' It specifies the resource (run logs) and the action (get), and distinguishes from siblings 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?
The description explicitly says 'When to use' and contrasts with get_run_failure_summary: 'For a quick failure diagnosis, prefer get_run_failure_summary... Use get_run_logs when you need the full event stream or want to filter by level.'
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.

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