Skip to main content
Glama

Explore Graph

synapse_explore_graph

Trace incoming callers, downstream callees, and nearby context in a codebase graph; detect circular dependencies directly via symbol, file path, or chunk ID.

Instructions

Explores structural relationships within the codebase graph. High-level actions include:

  • 'callers': finds all chunks that call a given chunk, with transitive depth support (1–3).

  • 'callees': finds all functions, modules, or types that a chunk calls or depends on, with transitive depth support (1–3).

  • 'context': retrieves rich structural context (callers, callees, related chunks) around a specific chunk.

  • 'cycles': detects circular dependencies reachable from a given chunk. All four actions accept chunk_id OR (repo_id + symbol) OR (repo_id + file_path + optional line) — no separate lookup needed.

REPLACES: grep_search for caller discovery, manual import tracing, find_references, caller guessing. Use this tool instead of these alternatives for better results with 30-60% fewer tokens via automatic compression.

Usage (short): Explore caller-callee dependency relationships and semantic context in the code graph. Pass symbol + repo_id directly — no separate lookup needed.

Usage (long): Trace incoming callers, downstream callees, detect cycles, or retrieve immediate neighbours/references for a code chunk. ALL four actions (callers, callees, context, cycles) accept:

  1. chunk_id (direct) — fastest, use when already known.

  2. repo_id + symbol — resolves the symbol and runs in one call.

  3. repo_id + file_path (+ optional line) — resolves by file position. Token-saving: both callers and callees support depth 1–3. Use depth: 2+ to get multi-hop results in a SINGLE call instead of chaining multiple depth-1 calls. One-call examples: callers: {action: 'callers', repo_id: 'MY_REPO', symbol: 'MyModule.my_fn', depth: 2} callees: {action: 'callees', repo_id: 'MY_REPO', symbol: 'MyModule.my_fn', depth: 2} cycles: {action: 'cycles', repo_id: 'MY_REPO', symbol: 'MyModule.my_fn'} Replaces manual import/caller guessing. Returns transitive callers/callees with depth control. Compression is on by default — graph results can be large.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesThe action to perform.
max_tokensNoApproximate final response budget in tokens (500-32000, default 4000).
compress_payloadNoSet false to disable lossless response-key compression.
Behavior4/5

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

With no annotations, the description carries full disclosure burden and does it well: it explains transitive behavior, depth 1–3, automatic compression, and warns graph results can be large. It doesn't explicitly state 'read-only,' but the action names and context imply no side effects.

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 longer than typical but well-structured with bullets, preprocessing examples, and front-loaded action list. There is some redundancy, such as telling the message that 'no separate lookup needed' and 'Replaces...manual caller guessing' twice, but the overall shape is usable.

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?

The behavior context is complete for a read-only, no-annotations, no-output-schema tool. It covers what is returned, how to specify targets, depth options, token-saving, compression, and which alternatives to replace. The agent has enough information to select and invoke the tool in most realistic graph-query scenarios.

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 already documents all three declared properties, so baseline is 3. The description adds real semantics: action values, how chunk_id/repo+symbol/file_path are accepted, depth behavior, and actual invocation examples. However, it references target fields like repo_id, symbol, and depth that are missing from the input schema, which oils any agent invocation and prevents a pointerfect score.

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 states the core purpose clearly: 'Explores structural relationships within the codebase graph' and then catalogs the four concrete actions. It distinguishes itself from siblings by naming grep_search, find_references, and caller guessing as alternatives it replaces.

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 explicit guidance on when to use the tool and what alternatives it replaces, plus three ways to specify a target and one-call examples. It also advises using depth 2+ for multi-hop results instead of chaining depth-1 calls.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/myelixlabs/synapse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server