Skip to main content
Glama

get_asset_dependents

Read-onlyIdempotent

Find all packages that reference an asset by name to see what breaks if you delete or move it. Lists incoming dependents with class, loaded state, and hard/soft dependency type.

Instructions

List every package that REFERENCES an asset (its incoming edges), each with its class and loaded state -- "who breaks if I delete or move this?", addressed by asset NAME. Direction matters: this is who needs IT; get_asset_dependencies is what it needs. Nearly the same query as get_asset_referencers -- prefer THAT one when the name could be ambiguous (it refuses to guess and echoes resolved_package, while this one silently takes the first /Game match), and prefer this one when you want the hard/soft split via dependency_type. Package-level edges only: use find_blueprint_node_references to find call sites inside graphs.

Returns: { asset_name: string, asset_path: string, dependents: [object], dependents_count: int, total_dependents: int, max_results: int, results_truncated: bool, exclude_engine: bool, dependency_type: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_nameYesExact asset name or full package name; the bare-name fallback scans /Game only and stops at the FIRST match, without reporting that others existed
max_resultsNoMaximum dependents to return, 1..50000 (default 5000). Read `results_truncated`: `total_dependents` counts the RAW registry edges before exclude_engine, so it can exceed dependents_count with nothing cut.
exclude_engineNoSkip /Engine and /Script referencers, default true. Filtered entries do NOT consume the max_results budget, but they ARE counted in total_dependents.
dependency_typeNoFilter by dependency kind: "hard", "soft", or "all" (case-insensitive), default "all"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes further by disclosing a genuine behavioral trap: this tool 'silently takes the first /Game match' for bare names, unlike the referencers sibling. It also constrains scope to package-level edges and spells out the return shape, adding value well beyond the annotations.

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?

Front-loaded with the core definition, then direction, then routing alternatives, then a Returns block. Dense but every clause contributes; the long referencers-comparison sentence is information-heavy but justified. Slightly noisy, so not a clean 5.

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?

There is no output schema, but the description inlines the return fields and key semantics (results_truncated, total_dependents vs dependents_count). Combined with direction, scope, and sibling routing, an agent has everything needed to call and interpret this correctly.

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 100%, so all four parameters are already documented in the input schema. The description restates dependency_type's hard/soft split and references results_truncated/total_dependents semantics, but adds little syntax or defaulting detail beyond what the schema carries. Baseline 3 applies when the schema does the heavy lifting.

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+resource with explicit scope: 'List every package that REFERENCES an asset (its incoming edges)'. It then distinguishes itself from get_asset_dependencies (reverse direction: 'this is who needs IT'), from get_asset_referencers (near-duplicate), and from find_blueprint_node_references (node-level). An agent can place this tool precisely 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 Guidelines5/5

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

Gives explicit alternative-selection rules: prefer get_asset_referencers when the name could be ambiguous (it echoes resolved_package), prefer this one for the hard/soft split via dependency_type, and use find_blueprint_node_references for call sites inside graphs. Both when-to-use-this and when-to-use-something-else are stated.

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