Skip to main content
Glama

trace_data_flow

Read-onlyIdempotent

Trace ordered call chains from a focal symbol to see how data flows through callers or callees. Set depth, direction, and target to map dependencies.

Instructions

The ordered call chain out from one entity. Two endpoints? trace_path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoHops from the focal (max 8).
focalYesStart entity: UUID or name.
targetNoA symbol to reach; its branch is kept.
compactNoAlias for include_body: false.
directionNo`calls`, `callers` or `both`.both
max_charsNoSoft cap on reply bytes.
include_bodyNoInline sources; false gives the shape.
limit_per_stepNoEdges kept per hop.
max_response_charsNoSame as `max_chars`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.7.17
    • changedInput schema / properties / compact / description
      Previous value: -"Alias for include_body: false. Ignored when include_body is given explicitly."New value: +"Alias for include_body: false."
    • changedInput schema / properties / depth / description
      Previous value: -"Maximum traversal depth from the focal (default 3, capped at 8)"New value: +"Hops from the focal (max 8)."
    • changedInput schema / properties / direction / description
      Previous value: -"Which way to walk: `calls` for callees, `callers` for callers, `both` merges."New value: +"`calls`, `callers` or `both`."
    • changedInput schema / properties / focal / description
      Previous value: -"Focal entity UUID or exact entity name to start tracing from"New value: +"Start entity: UUID or name."
    • changedInput schema / properties / include_body / description
      Previous value: -"Inline each step's source. False gives the chain's shape at a fraction of the size."New value: +"Inline sources; false gives the shape."
    • changedInput schema / properties / limit_per_step / default
      Previous value: -5New value: +12
    • changedInput schema / properties / limit_per_step / description
      Previous value: -"Edges kept per hop. Raise it for a node `clipped_steps` reports as cut."New value: +"Edges kept per hop."
    • changedInput schema / properties / max_chars / default
      Previous value: -12000New value: +24576
    • changedInput schema / properties / max_chars / description
      Previous value: -"Alias for max_response_chars, the spelling shared with the other retrieval tools."New value: +"Soft cap on reply bytes."
    • changedInput schema / properties / max_response_chars / default
      Previous value: -12000New value: +24576
    • changedInput schema / properties / max_response_chars / description
      Previous value: -"Serialized characters this response may occupy; the same parameter as `max_chars`."New value: +"Same as `max_chars`."
    • changedInput schema / properties / target / description
      Previous value: -"A symbol to reach, by exact name or UUID. Its branch survives the per-step cap first."New value: +"A symbol to reach; its branch is kept."
  2. First observedv0.7.16

TDQS

A3.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the single-source traversal scope and reveals nothing about output shape, truncation behavior at max_chars, or how depth/limit_per_step pruning affects results.

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?

Two short fragments, zero filler, with the core purpose front-loaded and the disambiguation sentence second. Every word earns its place.

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

Completeness2/5

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

This is a 9-parameter traversal tool with no output schema and no description of what is returned (tree structure, ordering guarantee, how truncation is signaled) or what happens when the focal cannot be resolved. Given the complexity, the description is too thin to be complete.

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% and all 9 parameters, including the alias pairs (compact/include_body, max_chars/max_response_chars), are documented inline. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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 ('the ordered call chain') and pins the scope ('out from one entity'), which distinguishes it from trace_path's two-endpoint traversal. An agent can pick between the two trace tools without opening either 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?

Provides an explicit routing rule: 'Two endpoints? trace_path.' That is a real when-to-use-this-vs-alternative signal. It stops short of a full 5 because it gives no exclusions or prerequisites (e.g. graph must be initialized, entity must exist).

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