Load a graph model from file and return its ID for subsequent queries. If the model was already auto-loaded at startup, returns the existing ID instantly.

Find code elements by name pattern. Use instead of grep for precise symbol lookup.

When to use:

• You know a class/function name but not its file location

• You want to find all implementations of a pattern (e.g., "Service", "*Handler")

• You need to locate a symbol before querying its dependencies

Parameters:

• query: Wildcards ("Service") or regex (".Service.") or substring ("Service")

• scope_path: Limit to subtree - faster, fewer results. Auto-set if server has default scope.

• element_types: Filter by ["class", "function", "method", "file", "dir"]

• model_id: Omit to use auto-loaded model

Returns JSON with match count and element list.

Query what code depends on an element, or what it depends on. THE KEY TOOL.

When to use:

• Before modifying a function: check incoming (what calls this?)

• Understanding a class: check outgoing (what does it use?)

• Planning refactoring: check both directions

• Check module-level dependency: "does src/web depend on src/db?"

Direction:

• "incoming": What uses THIS element (callers, importers) - for impact analysis

• "outgoing": What THIS element uses (callees, imports) - for understanding context

• "both": Both directions in one call

result_level (controls abstraction):

• None: Raw dependencies (function->function) - for precise call sites

• 4: File level - "which files depend on this?"

• 3: Directory level - "which directories depend on this?"

• 2: Repository level - "which repos depend on this?"

include_descendants:

• false (default): Only this element's own dependencies

• true: Also include children's dependencies. Relative paths (no leading /) show which descendant: "MyClass/Save -> /target (call)"

target_filter:

• Optional path prefix to filter results. Only dependencies whose target (outgoing) or source (incoming) starts with this prefix are returned.

• Example: target_filter="/project/src/db" with direction="outgoing" answers "does this module depend on src/db?"

WARNING: include_descendants=true on large directories (e.g., src/) can return thousands of results. Use target_filter or result_level=3 to keep output manageable.

Example - "Does src/web depend on src/db?": element_path="/project/src/web", direction="outgoing", include_descendants=true, result_level=3, target_filter="/project/src/db" -> Returns only dependencies from src/web subtree targeting src/db

Returns JSON with outgoing/incoming dependency lists.

Explore what's inside a file, class, or directory WITHOUT reading source code.

When to use:

• See what classes/functions a file contains (instead of Read + scroll)

• Explore a directory structure (instead of ls + recursive exploration)

• Understand class methods before diving into implementation

max_depth:

• 1: Direct children only (file->classes, dir->files)

• 2: Two levels (file->classes->methods) - usually sufficient

• 3+: Deeper nesting (rarely needed)

Returns JSON hierarchy with path, type, name, and children. Much cheaper than Read - use this first to decide what to read.

BEFORE modifying any public interface, call this to see what breaks.

Returns ALL abstraction levels at once (no need for multiple calls):

• detailed: Every function/method that uses this element

• by_file: Which files would need changes

• by_module: Which modules/repos are affected

Automatic warnings (when detected):

• dependency_cycle: bidirectional module deps — blast radius exceeds listed callers

• hub_element: >30 outgoing deps — changes cascade widely

When to use:

• Before changing function signature -> see all call sites

• Before renaming class -> see all importers

• Before deleting code -> verify nothing depends on it

• Planning large refactoring -> understand blast radius

Returns JSON with summary, warnings, and callers at multiple aggregation levels.

Run architectural health checks on the codebase. For occasional reviews, not daily use.

Available checks:

• "cycles": Find circular module dependencies (A depends on B, B depends on A)

• "hubs": Find modules with unusually high coupling (many dependencies)

aggregation_level controls module granularity:

• 2: /project/component (coarse, good for monorepos)

• 3: /project/component/module (default)

• 4+: deeper nesting for fine-grained analysis

Returns JSON with cycles, hub modules, and summary metrics.

Get all attributes (metadata) of a code element.

When to use:

• Check quality metrics (loc, risk_density, softagram_index)

• Check ownership info (backstage metadata, author counts)

• See security markers (secret_type, severity, outdated)

• Inspect any element metadata before deeper analysis

Returns element info + all attributes as flat key-value pairs. Only attributes that exist on the element are included.

Map sgraph path to local filesystem path. Use to find source code for NuGet packages.

When to use:

• You found a class/method in sgraph and need to read its source code

• You want to understand what a NuGet package method does internally

• You need to navigate from dependency analysis to actual code

The mapping is configured in sgraph-mapping.json. Default maps:

• /Organization///... -> /mnt/c/code//...

Returns:

• sgraph_path: Original path

• repo_name: Git repository name (3rd level in hierarchy)

• local_path: Resolved filesystem path

• exists: Whether the file/dir exists locally

After resolving, use the Read tool to view the source code.

Security overview across 6 dimensions: secrets, vulnerabilities, outdated/EOL, risk levels, backstage metadata, bus factor.

Use for: organizational security posture, audit preparation, risk prioritization.

Dimensions (only those with findings are included):

• secrets: potential secrets committed to code (API keys, tokens, national IDs)

• vulnerabilities: CVEs in dependencies, by severity

• outdated: end-of-life frameworks and approaching-EOL packages

• risk: code risk density and Softagram Index (0-100, higher=better)

• backstage: service ownership, lifecycle, public exposure

• bus_factor: single-author critical files, low-author repositories

Returns JSON with summary + per-dimension breakdown.

Run an openCypher query against the loaded model. Powerful and flexible.

Use this tool for complex graph queries that the other tools can't express:

• Multi-hop path queries, transitive dependencies

• Aggregation (count, group by)

• Complex filtering with AND/OR/NOT

• Joining different relationship types

The sgraph model is mapped to a labeled property graph:

Nodes (= code elements):

• Labels come from element type: :file, :class, :function, :dir, :method, etc.

• Properties: name, path (always present), plus all element attributes

• Elements without a type have no label

Relationships (= dependencies):

• Type comes from deptype: :imports, :function_ref, :call, :inc, :uses, etc.

• Properties: any edge-level attributes

• :CONTAINS relationships represent parent-child hierarchy (off by default)

Example queries:

"What files does main.py import?" MATCH (a:file)-[:imports]->(b:file) WHERE a.name = 'main.py' RETURN b.name, b.path

"Count dependencies per file, top 10:" MATCH (a:file)-[r]->(b) WHERE type(r) <> 'CONTAINS' RETURN a.name, count(r) AS deps ORDER BY deps DESC LIMIT 10

"Find all transitive imports from a file (up to 3 hops):" MATCH (a:file)-[:imports*1..3]->(b) WHERE a.name = 'app.py' RETURN DISTINCT b.name, b.path

"Files with more than 500 lines of code:" MATCH (f:file) WHERE f.loc > 500 RETURN f.name, f.loc ORDER BY f.loc DESC

"Does module A depend on module B? (directory-level)" MATCH (a)-[r]->(b) WHERE a.path STARTS WITH '/project/src/web/' AND b.path STARTS WITH '/project/src/db/' AND type(r) <> 'CONTAINS' RETURN type(r), count(r) AS cnt ORDER BY cnt DESC

Performance notes:

• include_hierarchy=false (default) is faster, omits :CONTAINS edges

• Enable include_hierarchy only for parent-child traversal queries

• Large models take a few seconds for initial indexing (cached per model)

• Variable-length paths (*1..N) with large N can be slow

Returns JSON array of result rows. Read-only: CREATE/DELETE/SET not supported.

Filter the model using SGraph Query Language — concise, architecture-native syntax.

Best for: filtering sub-models, checking module dependencies, attribute-based element selection. Returns a filtered model (elements + associations), not tabular data. For tabular queries and aggregation, use sgraph_cypher_query instead.

Syntax quick reference:

Element selection: "/project/src/web" Exact path (quoted, case-sensitive) phone Keyword (unquoted, case-insensitive partial match) "/path/*" Direct children "/path/**" All descendants

Attribute filters: @type=file Attribute equals (contains match) @type="file" Exact match (quoted value) @type!=dir Not equals @loc>500 Greater than (numeric) @loc<100 Less than @name=~".*.py$" Regex match @loc Has attribute (any value)

Dependency queries: "/src/web" --> "/src/db" Directed: does web depend on db? "/src/web" -- "/src/db" Undirected: dependency in either direction "/web" -import-> "/db" Filter by dependency type "*" --> "/src/db" Wildcard: anything that depends on db "/a" ---> "/b" Chain search: all transitive paths (DFS) "/a" --import-> "/b" Chain with type filter "/a" --- "/b" Shortest undirected path (BFS)

Logical operators: expr1 AND expr2 Sequential filter (intersection) expr1 OR expr2 Union NOT expr Complement (expr) Grouping

Examples: @type=file AND @loc>500 "/src" AND NOT "/src/External" "/src/web" --> "/src/db" (@type=file OR @type=dir) AND @loc>200

Returns JSON with elements (path, type, name) and associations (from, to, type).