Skip to main content
Glama

find_usages

Read-onlyIdempotent

Discover all calls and textual references to a symbol across your codebase, excluding its definition. Get one-hop usages through imports, decorators, docs, and more.

Instructions

Every use of a symbol: calls (from the graph when on) plus textual references (generics, decorators, imports, docs), definition excluded. Answers 'who uses X' at one hop; impact walks the chain further and adds the tests.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results.
sourceNoSource name. Omit when only one source applies.
symbolYesIdentifier to find the uses of.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: it details what countss as a use, that calls are included only when graph is on, and that the definition is excluded. This clarifies the tool's operational behavior beyond the annotation flags.

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 compact sentences with a clear front-loaded core statement. The first clause immediately states the tool's purpose, and the rest adds precise scope and sibling contrast without wasted words.

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?

For a query tool of moderate complexity, the description conveys what is included, excluded, and how it differs from the chain-walkng sibling. The schema covers parameter details, and annotations cover safety, so the description gives agents enough to select and invoke 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 the schema already documents all three parameters. The description does not add independent meaning to limit or beyond what the schema communicates, though it indirectly reinforces the source concept via 'graph when ond.' This meets the baseline for fully documented parameters.

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?

The description opens with a precise definition of what the tool does: 'Every use of a symbol' and enumerates exact kinds of uses (calls from graph, textual references). It explicitly distinguishes itself from impact by contrastings one-hop vs chain traversal, and clarifies that definition is excluded, separating it from find_definition.

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?

It clearly states when to uuse this tool (for one-hop 'who uses X') and names impact as the alternative when chain traversal and tests are needed, providing explicit routing guidance. It does not mention all siblings such as find_tests_for, but the impact contrast gives sufficient actionable context for the most likely alternative.

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