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 implies a read ('Get') and shows it accepts multiple keys in one call, but it does not state read-only semantics explicitly, behavior on missing/invalid keys, or any auth/rate-limit characteristics. An output schema already exists, so the extensive return-field listing adds little behavioral disclosure beyond structured data.

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

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

Front-loaded with the core purpose, then a parameter bullet, then a 'When to use' block — a clean structure. The long enumeration of return fields is partially redundant given an output schema exists, which costs a little efficiency.

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

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

Because an output schema exists, the return-value explanation is not strictly needed, but usage and the primary parameter are well covered. The only real gap is the undocumented env parameter, which is minor for a read tool of this shape.

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

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

Schema description coverage is 0%, so the description must compensate. It documents asset_keys well, including type and a concrete example (['my_extract', 'my_load']), but the second parameter, env, is never mentioned, leaving half the parameters undocumented.

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

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

States a specific verb and resource ('Get detailed metadata for one or more assets') and enumerates what that metadata includes: description, lineage, and partitions. It also distinguishes itself from the sibling search_assets by telling the agent to use that tool first when the key is unknown.

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

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

The 'When to use' block gives concrete conditions (understand lineage, check partitioning, get description) and names the alternative (search_assets) with the exact trigger for preferring it. Nothing about tool selection is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the non-obvious behavior that passing a group name expands to health for ALL assets in that group, and explains staleness semantics via the reasons[] field. It does not explicitly state read-only status, permission needs, or cost/latency implications of a group-wide call, so a small gap remains.

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

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

Front-loaded with the core purpose, then a scoping note, then a bulleted parameter explanation, then usage guidance. The returns list is somewhat redundant against the output schema but is short and aids scanning; no sentence is wasted and formatting is scannable.

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

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

For a two-parameter read tool with an output schema, the description covers purpose, scope, alternatives, and key result fields well. The only material omission is any mention of the env parameter, which leaves a minor blind spot given 0% schema coverage.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so thoroughly for the required asset_key_or_group parameter: dual meaning, concrete examples ('my_report' vs 'analytics'), and the group-expansion consequence. The second parameter, env, is never mentioned in the description or schema, which is the remaining shortfall.

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

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

States a specific verb and resource ('get a consolidated health view') plus the scope ('single asset or all assets in a group'), and explicitly positions itself against siblings by naming get_recent_materializations. An agent can distinguish it from get_asset_details or get_runs without opening any schema.

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

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

Contains an explicit 'When to use' clause (check freshness, find stale assets in a group, verify recent materializations succeeded) and an explicit alternative with the selecting condition ('Prefer this over get_recent_materializations when you need a health assessment rather than raw materialization history'). This is the when/when-not/alternative pattern in full.

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

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

No annotations are provided, so the description carries the full burden, and it delivers substantive behavioral context the schema cannot: the exact semantics of 'healthy' (all required daemons healthy AND no code location errors), the meaning of a high queued_runs_count, and that queued_runs_count_capped signals a floor rather than exact count on certain versions. It does not state the read-only/side-effect profile explicitly or mention auth or rate limits, so it falls short of 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.

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

Front-loaded with the core action and the 'START HERE' directive, then a scannable Returns list and a When-to-use block. Some bullets restate field shapes that the output schema already defines, so it is slightly longer than strictly necessary, but it is well organized and easy to parse.

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

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

An output schema exists, so enumerating return fields is partly redundant, but the description adds interpretation (bottleneck signal, capped-count caveat, health preconditions) that an agent needs to act on the result. The only real gap is the unexplained 'env' parameter; otherwise the definition is complete for a zero-required-param health check.

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

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

Schema description coverage is 0% and the description never mentions the single 'env' parameter, so an agent gets no guidance on what it selects or when to supply it. With one undocumented parameter, the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Get a global health check of the Dagster instance') and frames the scope as global/instance-level, which cleanly separates it from run-level siblings like get_run_status or get_run_stats. The 'START HERE for any monitoring workflow' line further anchors its role.

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

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

Explicit when-to-use guidance: first call in any diagnostic or monitoring flow, with a concrete branching rule (if healthy=false, check daemons and code_location_errors) and named follow-ups (list_code_locations, get_runs). Nothing is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return shape (runId, timestamp, assetKey, metadataEntries) but says nothing about permissions, error behavior for missing assets, or pagination. For an un-annotated read tool this is adequate but not rich.

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

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

Front-loads the core purpose, then structures return fields, parameter notes, and usage guidance as distinct blocks. Every line earns its place and the alternative tool is placed at the end where it belongs.

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

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

An output schema exists, so the description's return-value detail is a bonus rather than a requirement, and the when-to-use guidance is thorough. The one gap is the undocumented env parameter, which leaves an agent guessing about environment scoping.

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

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

Schema description coverage is 0%, so the description must compensate. It documents asset_key with a concrete example and explains limit's meaning, which is genuinely helpful, but the third parameter env is left completely unexplained in both schema and description.

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

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

States a specific verb and resource ('get the most recent materializations for an asset') with clear scope, and explicitly distinguishes itself from the sibling get_asset_health. An agent can tell what it returns (a list of materializations) without opening the schema.

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

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

Includes an explicit 'When to use' section listing three concrete scenarios (last materialization time, frequency tracking, metadata inspection) and names the alternative get_asset_health for a broader health view. Routing is unambiguous.

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

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

No annotations are provided, so the description carries the burden, and it does substantial work: it enumerates the response sections (failed_steps, root_cause_error, all_step_durations, suggestions) and discloses the non-failure behavior ('returns {message: Run did not fail.}'). It does not mention auth requirements or rate limits, but for a read-only diagnostic tool the behavioral surface is well covered.

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

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

Front-loaded with the one-line purpose, then structured return fields and a when-to-use section. Efficient sections with no filler sentences, though the enumerated return list is somewhat verbose given an output schema already exists.

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

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

An output schema exists, so the detailed return enumeration is redundant but not harmful. The routing guidance and failure/non-failure behavior make it complete enough to invoke correctly; the only real gap is unexplained parameter semantics, particularly the optional env.

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

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

Schema description coverage is 0% and the description never mentions either parameter. run_id is inferable from context, but env is entirely undocumented in both schema and description — its meaning, valid values, and default behavior are nowhere stated, so the description does not compensate for the coverage gap.

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

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

States a specific verb+resource ('consolidated failure diagnosis for a run') and immediately differentiates itself from siblings by naming get_run_status, get_run_logs, and get_run_stats as the calls it replaces. An agent can tell exactly what this tool does and how it differs from adjacent tools.

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

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

Explicit when-to-use ('always prefer this over get_run_logs for failed runs'), an explicit exclusion condition for the alternative ('use get_run_logs only when you need the full event stream'), and a scoping statement for investigating failed or canceled runs. Alternatives and their selection criteria are fully enumerated.

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

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

With no annotations, the description carries the full burden and largely meets it: it enumerates the returned fields (__typename, timestamp, message, level, stepKey, error details) and event categories, and discloses two non-obvious behaviors — the level_filter ordering semantics and that ExecutionStepFailureEvent/RunFailureEvent are always included at ERROR or below regardless of their level. It never explicitly states that the operation is read-only or what happens on a missing/invalid run_id, which is the remaining gap given zero annotation coverage.

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

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

Front-loaded with the one-line capability statement, then return contents, then a labeled parameter list, then a labeled 'When to use' block. No sentence is redundant and the structured layout makes the tool skimmable despite its length.

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

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

For a read-only log-retrieval tool with no annotations, the description supplies return contents, filtering semantics, pagination mechanics, and sibling routing. The output schema exists, so the return-value detail is bonus rather than a requirement, and nothing an agent needs to call this correctly is missing apart from the minor env omission.

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

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

Schema description coverage is 0%, so the description has to compensate, and it does for 4 of the 5 parameters — level_filter gets a thorough semantic explanation (ordering, threshold behavior, always-included failure events, default) and cursor/limit/run_id are all clarified. The env parameter is never mentioned in either the schema or the description, so one parameter remains completely opaque.

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

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

States a specific verb and resource ('Get structured log events for a run') plus the return shape, and explicitly distinguishes itself from the nearest sibling, get_run_failure_summary. An agent can separate this tool from the other 16 siblings without opening any schema.

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

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

Contains an explicit 'When to use' section that names the alternative (get_run_failure_summary) and the exact condition that selects it ('quick failure diagnosis'), then states when this tool is preferred ('full event stream or want to filter by level'). Both directions of the routing decision are covered.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the returned fields (runId, status, jobName, startTime, endTime, tags) and the limit default, which is genuinely useful, but says nothing about pagination/result caps, ordering guarantees, or what the 'env' scope does. For a list tool the safety profile is low risk, so this is adequate but incomplete.

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

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

Front-loads the one-line purpose, then return fields, then sibling routing, then grouped filtering, then worked examples. Every line is scannable and none is filler; the example block earns its space by making the filter syntax unambiguous.

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

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

An output schema exists, so return-value explanation is not strictly required, yet the description still names the fields, which is a bonus. Combined with the status enum and examples, an agent has nearly everything needed; the only real omission is any guidance on the undocumented 'env' parameter.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: job_name is explained with an example, statuses enumerates all eight valid values with example lists, and limit documents its default of 10. The gap is 'env', which is neither described in the schema nor mentioned in the description.

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

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

Starts with a specific verb+resource ('List recent pipeline runs') and immediately distinguishes itself from the many get_run_* siblings by declaring itself the entry point ('Start here to discover what has been running') and routing detailed lookups elsewhere. An agent can place it in the tool family without opening any schema.

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

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

Explicitly names the four drill-down alternatives (get_run_status, get_run_logs, get_run_stats, get_run_failure_summary) and chains to them via runId, then supplies three concrete invocation patterns ('Find recent failures', 'Check if a job ran today', 'Monitor active runs'). The when-to-use decision is fully specified.

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

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

With no annotations, the description carries the full burden. It does add helpful behavioral context by detailing the returned stepStats structure and practical use cases, and the 'Get' verb implies a read operation. However, it does not explicitly state read-only status, side-effect profile, permission requirements, or rate limits, leaving gaps in operational transparency.

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

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

The description is front-loaded with the core purpose, followed by a structured return summary and a clear usage paragraph. It is well organized, though the return-field detail is somewhat redundant given the presence of an output schema, and could be tighter.

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

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

For a two-parameter read tool with an output schema and no annotations, the description covers purpose, usage, return shape, and sibling routing well. However, it leaves the optional env parameter completely unexplained and provides no explicit safety or permission context, so important gaps remain for correct invocation.

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

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

Schema description coverage is 0% for both input parameters, and the description does not explain the required run_id or the optional env parameter. It mentions a 'run' conceptually but adds no format, default, or selection semantics beyond what the bare schema already encodes, so the parameter gap is entirely unaddressed.

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

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

The description states a specific verb and resource ('Get per-step execution statistics for a run') and enumerates the data returned (timing, materializations, expectations). It also explicitly distinguishes itself from a sibling, get_run_failure_summary, making the scope clear without opening schemas.

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

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

It gives explicit when-to-use guidance: find slow steps, check which steps materialized assets, or verify expectation results. It also names the preferred alternative for failed runs and the condition that selects it, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden, and it delivers real behavioral context: it explains that parentRunId signals re-execution and what resolvedOpSelection means, which goes beyond the structured fields. It still omits error behavior for an unknown run_id and any permission/auth expectations, keeping it short of 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.

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

It is front-loaded and organized into a purpose line, a Returns list, interpretation notes, and a When-to-use line, so it scans well. The Returns field enumeration partially duplicates the output schema, which is slight redundancy rather than waste.

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

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

Because an output schema exists, the description need not explain return values, and instead spends its budget on lineage semantics and usage routing, which is the right allocation. The one real hole is the undocumented env parameter, which leaves an agent guessing at its meaning.

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

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

Schema description coverage is 0% and there are two parameters: run_id is only loosely implied by 'a single run', and env is never mentioned anywhere in the description or schema. For a tool where the schema provides no parameter documentation, the description should have compensated and does not.

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

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

The description states a specific verb and resource ('Get full details for a single run') and enumerates the payload (status, config, tags, lineage), which clearly separates it from the list-oriented get_runs. It does not explicitly contrast with close siblings like get_run_logs or get_run_stats, so the differentiation is implied rather than stated.

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

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

The 'When to use' clause gives an explicit trigger ('after get_runs to inspect a specific run') and a second concrete use case (checking whether a run is a re-execution). It names the upstream alternative get_runs but gives no exclusions against the other get_run_* siblings, so routing is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden and does substantial work: it enumerates the returned fields (tick_id, status, timestamp, error, run_ids) and, more importantly, explains how to interpret each status/run_ids combination. It does not cover auth requirements, rate limits, or the read-only nature explicitly, so it falls just short of 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.

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

Front-loaded with the core purpose, then organized into a parameter block and a diagnostic block. Every bullet on interpretation carries signal, though the description runs somewhat long relative to a six-parameter read tool.

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

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

An output schema exists, so return-value structure need not be spelled out, yet the description still adds interpretive meaning on top of it. Nearly complete for correct invocation, with the undocumented 'env' parameter the only notable omission.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents five of six parameters including the effective enum for instigator_type ('SCHEDULE' or 'SENSOR') and the disambiguation role of repository_name/location_name. The 'env' parameter is never mentioned, leaving a real gap.

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

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

States a specific verb and resource ('Get recent tick history for a schedule or sensor') and immediately frames the diagnostic goal ('detecting silent failures'). This cleanly separates it from get_runs/get_run_logs, which operate on runs rather than ticks.

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

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

Explicit 'When to use: when a schedule or sensor is RUNNING but data is not being produced' plus four named diagnostic patterns that map observed results to causes. It also routes to a sibling alternative ('Missing ticks: daemon may be unhealthy — check get_instance_status') and names list_schedules/list_sensors as the source of valid names.

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

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 implies a read-only list operation but doesn't confirm safety, auth requirements, pagination, or behavior details. Only the return fields are listed, which is more about output than behavior.

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

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

Front-loads the purpose, then lists return fields and the limit parameter, and finishes with 'When to use.' Generally efficient, though listing all return fields is somewhat redundant given an output schema exists.

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

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

For a 2-param tool with no annotations and a documented output schema, the description covers purpose and one parameter but omits 'env', auth/prereqs, and sibling routing. It's adequate but has clear gaps.

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

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

Schema coverage is 0%, so the description should compensate. It explains 'limit: max backfills to return (default 10),' adding meaning for one parameter. The 'env' parameter is entirely undocumented in both schema and description, leaving a gap.

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

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

States a specific verb+resource ('List recent asset backfills with their status and partition progress'), clearly distinguishing it from run-oriented siblings like get_runs or get_recent_materializations. It's a bit generic but the resource domain (backfills) is unique among siblings.

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

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

Provides 'When to use: to monitor in-progress backfills or review recent ones,' which gives implied usage context. However, it doesn't contrast against alternatives (e.g., get_recent_materializations or get_runs) or state when not to use it.

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

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

No annotations, so the description carries the full behavioral burden. It does describe return shape (name, loadStatus enum values, repositories or PythonError), which is useful, but since an output schema exists the return detail is somewhat redundant with structured data. It adds the load-failure retry path, a genuinely useful behavioral fact.

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

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

Front-loaded 'List all...' then return details then usage. Every sentence earns its place; no waste. Slightly dense but structured well.

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

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

Output schema exists, so return values needn't be fully enumerated in prose (though they are). The description covers the main usage scenarios and a successor tool, but omits any mention of the env parameter, leaving a small but notable gap for an otherwise simple tool.

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

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

Only one optional param (env) with 0% schema description coverage, but the value should come from the description. The description mentions nothing about env, leaving the sole parameter undocumented. Baseline for a single optional param is modest, but this gap is a real loss.

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

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

States a specific verb (list) and resource (code locations and their load status). It doesn't explicitly differentiate from sibling list tools, but no sibling covers code locations, so the resource itself is distinct enough.

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

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

Explicitly gives 'When to use' triggers (after deployment, when get_instance_status reports errors) and names a related sibling action (reload_code_location). No 'when-not-to-use', but the routing context is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses that filtered calls raise when a relevant code location failed to load or is still loading, while an unfiltered call never raises. It also defines empty-result semantics, though it omits pagination or read-only confirmation beyond the implied 'List'.

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

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

Front-loaded with the core purpose and the returned fields, then filtering semantics, then edge cases, then usage. Every sentence is substantive, with only minor repetition around 'check list_code_locations' appearing twice.

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

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

An output schema exists, so return values needn't be documented, yet the description usefully names the per-job fields anyway. Filtering, error behavior, and usage are all covered; only the env parameter and pagination behavior remain unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for two of three params: repository_name and location_name are independent exact-match filters that combine with AND semantics. The env parameter is never explained in either schema or description, which is the remaining gap.

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

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

States a specific verb and resource ('List jobs across code locations') plus the optional filter dimensions. It also names the related siblings (list_code_locations, get_instance_status, launch_job) so the agent can distinguish this from its neighbors without opening any schema.

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

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

Has an explicit 'When to use' section: as a starting point to explore jobs, or to find the exact job name and repository_location needed for launch_job. It also clarifies the alternative path (use list_code_locations or get_instance_status to check load health), leaving nothing to inference.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose an important failure semantic: it raises when a code location is unavailable instead of returning a partial list that could be mistaken for complete. It does not cover auth requirements, rate limits, or pagination, so it falls short of fully compensating for the missing annotations.

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

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

Well front-loaded and organized into purpose, return shape, and when-to-use. Slightly redundant: the opening sentence lists the same fields (status, cron expression, target job, next tick) that the following 'Returns per schedule' sentence re-enumerates in expanded form.

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

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

For a single-parameter read tool with an output schema present, the description covers purpose, usage routing, and error behavior adequately, and its return-value detail is optional redundancy rather than a gap. The one real omission is any explanation of the 'env' parameter.

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

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

There is one parameter ('env') at 0% schema description coverage, and the description never mentions it — no guidance on what environment values are valid, what the default null means, or whether it scopes the listing. The schema does not compensate, so the agent is left guessing about the tool's only input.

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

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

States a specific verb and resource ('List all schedules') and enumerates the exact fields returned (status, cron expression, target job, next tick), which lets an agent distinguish it from siblings like list_jobs or list_sensors without opening any schema.

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

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

Explicit 'When to use' block names three concrete scenarios (check active schedules, verify cron timing, find stopped schedules) and routes the agent to get_tick_history for the specific failure mode of a RUNNING schedule whose jobs aren't executing. That is a named alternative plus the condition that selects it.

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

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

With no annotations, the description carries the behavioral burden and does disclose a meaningful failure trait: it raises when a code location is unavailable rather than returning a partial list that could be mistaken for the complete set. It does not state read-only semantics, permissions, or whether the env parameter affects visibility, but the error contract is a genuinely useful disclosure.

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

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

Front-loaded with purpose, then returns, then usage, then edge-case behavior — a clean progression with no filler. The return-field enumeration is somewhat redundant given an output schema exists, which keeps it just short of a 5.

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

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

Covers purpose, usage, alternative routing, and error semantics well enough for an agent to call it correctly, and the output schema means return values did not need restating. The only real gap is the undocumented env parameter.

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

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

There is one parameter (env) with 0% schema description coverage, so the description is the only place its meaning could be explained — and it never mentions env at all. The rich description of return fields does not compensate for the undocumented input parameter.

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

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

States a specific verb and resource ('List all sensors') plus scope ('with their status and target jobs'), and enumerates the returned fields so an agent knows exactly what it gets. It is clearly distinguishable from siblings like list_jobs, list_schedules, and get_tick_history.

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

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

Provides an explicit 'When to use' clause (check which sensors are active and what jobs they trigger) and names the alternative tool get_tick_history with the exact condition that selects it (RUNNING but not producing runs). Nothing is left to inference.

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

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

No annotations are provided, so the description carries the burden. It states it is read-only, does not launch a run, and does not filter external/observable/non-executable/partitioned matches. However, it does not state authentication requirements, rate limits, or potential side effects beyond no launch.

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

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

The description is front-loaded with purpose, followed by a structured syntax list and return information. It is appropriately sized for a complex syntax tool, though the syntax examples could be slightly condensed.

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

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

Given the tool's complexity (syntax parsing) and that an output schema exists, the description is nearly complete: it explains syntax, return format, and read-only behavior. It misses guidance on the 'env' parameter and explicit when-to-use vs alternatives, but covers the core resolution behavior well.

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

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

Schema description coverage is 0%, so parameters are undocumented. The description provides extensive detail about the supported syntax for 'asset_selection', but does not explain the 'env' parameter or the expected format for asset_selection's top-level structure beyond syntax examples. This partially compensates but leaves the env parameter ambiguous.

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

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

States a specific verb (resolve), resource (Dagster asset-selection syntax into concrete assets), and explicitly distinguishes from launching a run. This clearly differentiates it from 'search_assets' and other read-only tools in the sibling list.

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

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

The description implies usage: it resolves syntax without launching a run and its output is ready to pass to materialize_assets or backfill_assets. However, it does not explicitly name when to use this vs search_assets or how it differs from listing assets via get_asset_details.

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

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

With no annotations, the description carries the burden and mostly does: it discloses case-insensitive substring matching, exact group matching, combinability, and that passing neither filter returns ALL assets. That unbounded-default disclosure is genuinely useful. It stops short of pagination, result limits, or whether ordering is guaranteed.

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

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

Front-loaded purpose followed by tight bullets, with the highest-value routing guidance last. The 'Returns per asset: ...' line partially duplicates the output schema and is the one sentence that does not fully earn its place.

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

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

An output schema exists so return values need not be spelled out, and the description nonetheless covers discovery intent, filter semantics, and the default-all behavior. Missing only pagination/limit behavior and any explanation of the 'env' parameter.

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

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

Schema description coverage is 0%, so the description must compensate — and it documents prefix and group well, including matching semantics and examples. However, the third parameter 'env' is never mentioned in either the schema or the description, leaving a genuine gap.

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

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

States a specific verb and resource ('Search and list assets') and scopes it to two filter modes, name prefix and group. It also names the siblings it precedes (get_asset_details, get_asset_health), so the agent can separate discovery from detail/health lookups without opening a schema.

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

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

Explicit 'When to use' section names the downstream tools it feeds and prescribes which filter to pick ('prefix for fuzzy search, group for scoped listing'). It also states the no-filter fallback, removing the main ambiguity for an all-optional-parameter tool.

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