Skip to main content
Glama
khoitd-voyager

mcp-spec-nav

by khoitd-voyager
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

spec_nav_callers

Find call sites of a function or method across a repo before changing its signature or behavior. Narrow results by class, file, or service and separate confirmed from uncertain sites.

Instructions

Call sites of a function or method across the repo, before changing its signature or behaviour. Narrow with "Class.method", className or file. TS/JS (and Vue/Svelte/Astro) are resolved with the type checker, so same-named methods on other classes are excluded; other languages are bound by evidence and each site's reason says which. likely, ambiguous, unresolved and dynamic sites are listed apart and are not confirmed callers. exhaustive is true only when type-checked targets have nothing left open; names computed at runtime, HTTP/RPC/queue calls and code outside the repo are never counted. Paged: partial names what is not shown yet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoFile declaring the function, relative to the root (narrows the target).
limitNoSites per page (default 100).
cursorNoThe nextCursor from the previous page. Repeat the other arguments unchanged.
formatNo"text" (default, compact) or "json" (structured).
symbolYesFunction or method name, e.g. "recordHistory" or "OrderService.recordHistory"
serviceNoWhere the function is declared (narrows which declaration is meant). Call sites are searched repo-wide.
classNameNoClass (or object/namespace) declaring the method.
searchServicesNoServices/directories relative to the root (e.g. "services/api"); "." is the root project's own files. Default: the whole repo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • changedInput schema / properties / searchServices / description
      Previous value: -"Limit to these services/directories, relative to SPEC_NAV_ROOT (e.g. \"services/api\", \"packages\"). \".\" is the root project's own files. Omit to cover the whole repo — the default."New value: +"Services/directories relative to the root (e.g. \"services/api\"); \".\" is the root project's own files. Default: the whole repo."
  2. First observedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations the description carries the full burden and does so richly: type-checker resolution for TS/JS/Vue/Svelte/Astro, evidence-based binding elsewhere, the separation of likely/ambiguous/unresolved/dynamic from confirmed callers, the meaning of `exhaustive`, explicit exclusions (runtime-computed names, HTTP/RPC/queue calls, out-of-repo code), and pagination via `partial`.

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?

Purpose is front-loaded and every sentence carries information, but it is a dense unbroken paragraph; light structuring would improve scannability without losing content.

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?

No output schema exists, yet the description explains the returned categories (likely/ambiguous/unresolved/dynamic), the `reason` field, and the `exhaustive`/`partial` flags. For a tool of this complexity, an agent has what it needs to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds combined meaning — how symbol/className/file/service/searchServices narrow the target, the 'Class.method' syntax, and the paging contract. It clarifies interplay the per-parameter schema text leaves implicit.

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 — 'Call sites of a function or method across the repo' — and immediately frames the intent ('before changing its signature or behaviour'). This is clearly distinguishable from definition-oriented siblings like spec_nav_find_functions or spec_nav_read_function.

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?

Gives a clear use context ('before changing its signature or behaviour') and narrowing guidance ('Narrow with Class.method, className or file'). It does not explicitly name an alternative sibling or state when-not to use it, so it stops short of a 5.

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