Skip to main content
Glama

check_asset_circular_dependency

Read-onlyIdempotent

Detect circular dependencies in an Unreal asset's dependency graph via depth-first search, returning the cycle path and length to diagnose cook failures and load-order issues.

Instructions

Depth-first search of an asset's dependency graph looking for a CYCLE, returning has_circular_dependency plus the actual circular_path that closes the loop and its length -- the diagnosis for cook failures, load-order surprises and Blueprints that will not compile in isolation. Complements get_asset_dependencies (one level out) and get_asset_dependencies_recursive (the whole closure without cycle detection). WARNING: check search_limit_reached before trusting a false: the walk stops at max_depth / max_visited, and a cycle beyond those limits reads exactly like no cycle at all.

Returns: { asset_name: string, asset_path: string, has_circular_dependency: bool, nodes_visited: int, max_depth_reached: int, search_limit_reached: bool, circular_path: [string] (the cycle itself, its first package repeated at the end), cycle_length: int (packages in the cycle), root_in_cycle: bool, lead_in_path?: [string] (root ... first package of the cycle, when the root only leads into it), suggestion?: string (the edge that closes the cycle), dependency_type: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_depthNoMaximum recursion depth, default 100. Hitting it sets search_limit_reached and makes a `false` answer inconclusive.
asset_nameYesExact asset name or full package name; the bare-name fallback scans /Game only and takes the first match
max_visitedNoMaximum total nodes visited, default 10000. Hitting it also sets search_limit_reached.
dependency_typeNoFilter by dependency kind considered at every DFS step: "hard", "soft", or "all" (case-insensitive), default "all"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the WARNING that a false result is inconclusive when the walk hits max_depth/max_visited, which directly governs how the agent interprets output.

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 core purpose is front-loaded in the first clause before sibling comparisons and the return shape. The Returns enumeration is long but structured and each field earns its place; only slight verbosity keeps it from a 5.

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?

No output schema exists, but the description enumerates the return object fully (including circular_path, cycle_length, root_in_cycle, lead_in_path, suggestion), and annotations cover the safety profile. Complete for an agent to call and interpret it, with only minor gaps around dependency_type filtering nuance.

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 100%, so the schema already documents all four parameters including defaults and the search_limit_reached consequence. The description restates the limit-warning concept but adds little parameter-specific detail beyond what the schema provides, making 3 the correct baseline.

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?

States a specific verb and resource (DFS of an asset's dependency graph looking for a cycle) and immediately distinguishes itself from the two relevant siblings by name and scope: get_asset_dependencies (one level out) and get_asset_dependencies_recursive (whole closure without cycle detection). An agent can tell it apart 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.

Usage Guidelines4/5

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

Frames the diagnostic use cases explicitly (cook failures, load-order surprises, Blueprints that won't compile in isolation) and routes the agent away from the sibling dependency tools. It stops short of an explicit 'do not use this when...' exclusion, but the alternatives and their conditions are named.

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

Deploy Server

Other Tools