Code Pathfinder

Search docker-compose services with filtering. Supports configuration filters (has_privileged, has_volume, exposes_port). Returns: - service_name, file, line - Configuration (image, build, ports, volumes, environment, privileged, network_mode) Use when: Finding specific services, analyzing service configurations, or understanding multi-container architecture. Examples: - find_compose_services(has_privileged=true) - find privileged containers - find_compose_services(has_volume="/var/run/docker.sock") - find services with Docker socket - find_compose_services(exposes_port=8080) - find services on port 8080 - find_compose_services(service_name="db") - find database services - find_compose_services(file_path="docker-compose.yml") - get all services from specific file

Search Dockerfile instructions with semantic filtering. Supports instruction-specific filters (has_digest for FROM, user for USER, port for EXPOSE). Returns: - file, line, instruction, raw_content - Parsed details (base_image, tag, digest for FROM; user, group for USER; port, protocol for EXPOSE) Use when: Finding specific instructions, locating images, analyzing exposed ports, or understanding Dockerfile structure. Examples: - find_dockerfile_instructions(instruction_type="FROM", has_digest=false) - find unpinned base images - find_dockerfile_instructions(instruction_type="USER", user="appuser") - find specific user - find_dockerfile_instructions(instruction_type="EXPOSE", port=8080) - find services on port 8080 - find_dockerfile_instructions(instruction_type="FROM", base_image="python") - find Python-based images - find_dockerfile_instructions(file_path="api/Dockerfile") - get all instructions from specific Dockerfile

Search for Python modules by name. Returns module information including file path and symbol counts. Returns: module_fqn, file_path, functions_count (number of functions/methods in the module), and match_type (exact/partial). Use when: Finding module locations, understanding module structure, or navigating between modules. Examples: - find_module("myapp.auth") - find the auth module - find_module("utils") - find all modules named utils - find_module("models.user") - find user module in models package

Search and filter symbols by name and/or type. Supports Python, Go, and Java. Supports partial matching. Results are paginated. Symbol Types Available: - Python Functions: function_definition, method, constructor, property, special_method - Python Classes: class_definition, interface (Protocol/ABC), enum, dataclass - Python Variables: module_variable, constant (UPPERCASE), class_field, parameter - Go Functions: function_declaration, init_function, method, func_literal - Go Types: struct_definition, interface, type_alias - Go Variables: package_variable, constant, variable_assignment Returns: For ALL symbols: fqn, file, line, type, symbol_kind (LSP integer), symbol_kind_name (human-readable). For functions/methods: return_type, parameters, decorators. For classes: superclass, interfaces. For fields: inferred_type, confidence, assigned_in. For parameters: inferred_type (type annotation), parent_fqn (containing function). LSP Symbol Kinds: Function(12), Method(6), Constructor(9), Property(7), Operator(25), Class(5), Interface(11), Enum(10), Struct(23), Variable(13), Constant(14), Field(8). Filtering: At least ONE of name/type/types/module must be provided. Filters can be combined (e.g., name="get" + type="method" + module="core.utils"). Use when: Looking for symbols by name; filtering by type; exploring codebase structure; finding definitions; analyzing symbol types; drilling down into specific modules. Examples: - find_symbol(name="login") - finds all symbols named login - find_symbol(type="method") - lists all methods - find_symbol(types=["interface","enum"]) - lists all interfaces and enums - find_symbol(name="get", type="method") - finds methods named "get" - find_symbol(name="User", type="class_definition") - finds User class only - find_symbol(module="core.settings") - finds all symbols in core.settings module - find_symbol(type="constant", module="core.settings.base") - finds constants in specific module - find_symbol(module="data_manager", type="method")…

Get detailed information about a SPECIFIC call from one function to another. Most detailed view of a single call site. Returns: Full call site info including caller FQN, target, exact location (file, line, column), arguments passed, and resolution details (resolved status, failure reason if unresolved, type inference info). Use when: Investigating a specific function call, understanding how arguments are passed, debugging why a call wasn't resolved, or analyzing type inference. Examples: - get_call_details("handle_request", "authenticate") - how does handle_request call authenticate? - get_call_details("save_user", "execute") - examine the database call in save_user

Find all functions CALLED BY a given function (forward call graph / outgoing edges). Answer: "What does this function depend on?" Results are paginated. Returns: Source function info, list of callees with target name, call line, resolution status (resolved/unresolved), and type inference info if available. Includes pagination info. IMPORTANT - Function Parameter Requirements: - Must be a FUNCTION or METHOD name, NOT a module path - Use find_symbol first to get the exact FQN of the function you want to analyze - Short names work ("process_payment") if the function name is unique - Full FQNs are preferred ("myapp.payment.process_payment") to avoid ambiguity - Method names should include class ("Payment.process" or "myapp.models.Payment.process") - Test files are NOT indexed - only production code is queryable What WORKS: ✓ "myapp.payment.process_payment" - function FQN ✓ "Payment.process" - method with class name ✓ "process_payment" - short function name (if unique in codebase) ✓ "myapp.models.Task.update_status" - full method FQN What DOESN'T work: ✗ "myapp.payment" - this is a module, not a function ✗ "test_process_payment" - test files are not indexed ✗ Module-level code that isn't wrapped in a function Type Inference in Results: - Callees resolved via cross-file import resolution include "type_inference" metadata - Shows inferred_type (e.g., "django.db.models.JSONField") for method calls on imported classes - Confidence score (0.0-1.0) indicates resolution certainty - High confidence (>0.9) means the call was resolved using import analysis Use when: Understanding function dependencies, analyzing what a function does, tracing data flow FROM a function, finding unresolved external calls, or analyzing cross-file method calls. Examples: - get_callees("process_payment") - what functions does payment processing call? - get_callees("myapp.payment.process_payment") - dependencies with full FQN - get_callees("User.save") - what does the User.save method call? - get…

Find all functions that CALL a given function (reverse call graph / incoming edges). Answer: "Who uses this function?" Results are paginated. Returns: Target function info and list of callers with their FQN, file, line number, and the specific call site location. Includes pagination info. IMPORTANT - Function Parameter Requirements: - Must be a FUNCTION or METHOD name, NOT a module path - Use find_symbol first to get the exact FQN of functions - Short names work ("sanitize_input") if unique in the codebase - Full FQNs are preferred ("myapp.utils.sanitize_input") to avoid ambiguity - Method names should include class ("MyClass.save" or "myapp.models.MyClass.save") - Test files are NOT indexed - only production code is queryable What WORKS: ✓ "myapp.auth.login" - function FQN ✓ "User.save" - method with class name ✓ "sanitize_input" - short function name (if unique) ✓ "myapp.models.Project.get_all_tasks" - full method FQN What DOESN'T work: ✗ "myapp.auth" - this is a module, not a function ✗ "test_login" - test files are not indexed ✗ Module-level code without a function wrapper Use when: Understanding function usage, impact analysis before refactoring, finding entry points, or tracing how data flows INTO a function. Examples: - get_callers("sanitize_input") - who calls the sanitize function? - get_callers("myapp.auth.login") - who calls the login function? - get_callers("User.save") - who calls the User.save method?

Retrieves dependency information for Docker entities (compose services or Dockerfile stages). Use cases: - Map docker-compose service dependencies (depends_on relationships) - Analyze multi-stage Dockerfile build dependencies (COPY --from) - Traverse upstream/downstream dependency chains Examples: - get_docker_dependencies(type="compose", name="web") - find all dependencies for "web" service - get_docker_dependencies(type="dockerfile", name="builder", file_path="Dockerfile") - find stage dependencies - get_docker_dependencies(type="compose", name="api", direction="upstream", max_depth=2) - upstream only, 2 levels Parameters: - type: Entity type - "compose" for docker-compose services or "dockerfile" for Dockerfile stages (required) - name: Entity name - service name (for compose) or stage name/alias (for dockerfile) (required) - file_path: Filter to specific file path (optional) - direction: Traversal direction - "upstream" (dependencies), "downstream" (dependents), or "both" (default: "both") - max_depth: Maximum traversal depth (default: 10) Returns: - target: Target entity name - type: Entity type (compose or dockerfile) - file: Source file path - line: Line number - direction: Traversal direction used - max_depth: Maximum depth used - upstream: Array of dependencies (entities this depends on) - downstream: Array of dependents (entities that depend on this) - dependency_chain: Simple chain string (e.g., "db → api → web")

Get complete breakdown of a Dockerfile with all instructions and multi-stage analysis. Returns: - file, total_instructions - instructions: Array of parsed instructions with details - multi_stage: is_multi_stage, base_image, stages (array of stage aliases) - summary: has_user_instruction, has_healthcheck, unpinned_images Use when: Understanding complete Dockerfile structure, analyzing multi-stage builds, or reviewing all instructions. Examples: - get_dockerfile_details(file_path="/app/Dockerfile") - get complete Dockerfile breakdown - get_dockerfile_details(file_path="Dockerfile") - analyze Dockerfile in current context

Get comprehensive statistics about the indexed codebase (Python, Go, Java). Use this FIRST to understand the project scope before making other queries. Returns: - Project info: project_path, python_version, indexed_at, build_time_seconds - Overall stats: total_symbols, call_edges, modules, files, taint_summaries, class_fields - symbols_by_type: Breakdown by all 13 Python types (function_definition, method, constructor, property, special_method, class_definition, interface, enum, dataclass, module_variable, constant, class_field, parameter) - symbols_by_lsp_kind: Breakdown by LSP Symbol Kind (Function, Method, Constructor, Property, Operator, Class, Interface, Enum, Struct, Variable, Constant, Field) - top_modules: Top 10 modules by function count - health: Index health indicators (average functions per module, etc.) Use when: Starting analysis, understanding project size and structure, verifying index quality, or exploring symbol distribution.

List all Python modules in the indexed project. Returns comprehensive module information. Returns: Array of modules with module_fqn, file_path, and functions_count for each. Includes total_modules count. Use when: Exploring project structure, getting an overview of all modules, or discovering what modules exist. Examples: - list_modules() - get all modules in the project

Resolve a Python import path to its actual file location in the project. Returns: Import resolution with file_path, module_fqn, match_type (exact/short_name/partial/ambiguous), and alternatives if multiple matches exist. Use when: Finding where a module is defined, understanding import structure, or locating source files for external references. Examples: - resolve_import("myapp.auth.users") - find the users module - resolve_import("utils") - find modules named utils (may return multiple) - resolve_import("database") - locate database module

Returns the current server state: indexing phase, progress, and readiness. Use when: Checking whether the index is ready before making queries, or diagnosing slow startup. Returns: state (uninitialized/indexing/ready/failed), progress details, stats (when ready), and optional update-check fields (latest_version, update_message, announcement) when a newer version or operator announcement is available.