SwiftKG MCP Server

Overview Schema Source Related Servers Discussions Admin

callers

Find every caller of a specific code node, including cross-module references via sym: stubs. Use with custom relation types to discover subclasses, conformers, or importers.

Instructions

Return all nodes that call a given node, resolving through sym: stubs.

Unlike query_codebase (which seeds on semantics and expands outward), this tool performs a precise reverse lookup: it finds every caller of the specified node, including cross-module callers that reference it via an import alias recorded as a sym: stub.

The rel parameter accepts any edge relation, not just CALLS::

callers(node_id, rel="INHERITS")    # find all subclasses
callers(node_id, rel="CONFORMS")    # every type conforming to a protocol
callers(node_id, rel="IMPORTS")     # find all importers

Typical workflow::

# 1. Resolve the exact node ID
get_node("meth:Sources/Networking/Client.swift:HTTPClient.send")

# 2. Find all callers (production code only)
callers("meth:Sources/Networking/Client.swift:HTTPClient.send", paths="Sources/")

:param node_id: Target node identifier, e.g. cls:Sources/Networking/Client.swift:HTTPClient. :param rel: Relation type to invert (default "CALLS"). :param paths: Comma-separated module path prefixes to include, e.g. "Sources/" to exclude test callers. Empty string (default) returns all callers. :return: JSON with node_id, rel, caller_count, and callers list of node dicts.

Input Schema

TableJSON Schema

Name	Required	Default
`rel`	No	CALLS
`paths`	No
`node_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 10, 2026

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It explains stub resolution, cross-module callers, and rel flexibility. The return format is also disclosed. However, it doesn't mention potential performance costs, error behavior, or side effects (which are minimal). Slightly more detail on operational behavior would be ideal, but it is substantially transparent.

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 moderately long but well-structured with clear sections: purpose, rel examples, workflow, params, and return. It avoids fluff and every sentence adds value. Slightly verbose but organized enough for efficient scanning.

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?

Given the tool's complexity (multiple parameters, flexible relation types) and the absence of annotations, the description is remarkably complete. It covers the operation, usage context, parameter semantics, and result shape. An agent can confidently select and invoke this tool without further digging.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. It fully documents node_id, rel, and paths with concrete examples, defaults, and even describes the return format. There is no gap between the schema and the description; it covers everything the agent needs to invoke it correctly.

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 precise verb (return all nodes that call a given node) with a specific resource (node via sym: stubs). It also explicitly contrasts with query_codebase, making it easy for an agent to distinguish.

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?

Provides a clear when-to-use: a reverse lookup vs query_codebase's semantic expansion. Includes a workflow example and explains the rel parameter for non-CALLS relations. Explicitly covers alternatives and exclusions (e.g., paths to exclude tests).

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