Skip to main content
Glama

find_references

Read-onlyIdempotent

Locate callers, importers, and references for a code entity. Trace data flow by query or entity ID to see who uses or depends on it.

Instructions

Callers, importers and references of one entity. Chains? trace_data_flow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoName; a section per owner sharing it.
entity_idNoUUID, or give query.
max_charsNoSoft cap on reply bytes.
answer_onlyNoFalse adds coverage and candidates.
relation_kindsNocalls, imports or references.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.7.17
    • addedInput schema / properties / answer_only
      Added value: +{
      +  "default": true,
      +  "description": "False adds coverage and candidates.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / entity_id / description
      Previous value: -"Exact entity UUID. Optional if query is provided."New value: +"UUID, or give query."
    • changedInput schema / properties / max_chars / description
      Previous value: -"Serialized characters this response may occupy; what was cut is named in `elisions`."New value: +"Soft cap on reply bytes."
    • changedInput schema / properties / query / description
      Previous value: -"Exact symbol name to resolve. Optional if entity_id is provided."New value: +"Name; a section per owner sharing it."
    • changedInput schema / properties / relation_kinds / description
      Previous value: -"Filter to calls, imports or references. Defaults to all three."New value: +"calls, imports or references."
  2. First observedv0.7.16

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false). The description adds the 'one entity' scoping constraint and the kinds of references returned, which is useful context beyond annotations, but it says nothing about result structure, completeness, or performance. A 3 reflects annotations doing most of the behavioral work.

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 extremely short with no wasted words, and the core purpose is front-loaded. The telegraphic 'Chains? trace_data_flow.' phrasing is terse but still readable.

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?

With no output schema and five optional parameters, the description should explain return format (e.g., section-per-owner, what answer_only changes) and how to specify the entity when neither query nor entity_id is required. It only gives the broad category of references returned, leaving an agent without enough context to interpret results.

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 the schema already documents all five parameters. The description adds no syntax, format, or interaction details beyond what the schema provides, making the baseline 3 appropriate.

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

Purpose4/5

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

States a specific resource and scope: 'Callers, importers and references of one entity.' An agent can tell what is returned, and the reference to trace_data_flow gives partial sibling differentiation. The missing verb is a minor gap, but the purpose is clear.

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

Usage Guidelines3/5

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

The fragment 'Chains? trace_data_flow.' names an alternative and the condition that selects it, which is explicit routing guidance. However, it omits when-not conditions relative to other plausible siblings like get_entity_source or semantic_search, leaving usage only partially covered.

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