Graph Intelligence

The graph layer is exposed via a CLI with 15 subcommands:

Analysis Commands

Camel-Specific Commands

Context Commands

Output Commands

Graph queries were moved out of MCP and into the local CLI because:

• MCP adds latency — Each graph query becomes a round-trip to the MCP server
• CLI is faster — Direct process execution with stdout/stderr
• Simpler architecture — One less MCP server to maintain
• No extra graph server — Generated projects keep the Camel, Knowledge, and Citrus MCP servers, while graph analysis stays local

graph generate builds the property graph and persists it at .camel-kit/project-graph.json by default:

cd /path/to/project
camel-kit graph generate

Query commands read that file. Regenerate it after source changes so queries reflect the current project. You can choose another output for generation with --output and pass a graph file to queries with --graph-file.

graph visualize reads .camel-kit/project-graph.json by default and writes the interactive page to .camel-kit/project-graph.html.

The impact command computes bounded transitive reachability in the requested direction, capped at 50 nodes per direction. The direction can be upstream, downstream, or both; it defaults to both.

Query:

camel-kit graph impact class:com.example.OrderServiceImpl --direction upstream

Output shape:

{
  "found": true,
  "total": 1,
  "byType": {
    "CLASS": [
      {
        "id": "class:com.example.OrderRoute",
        "type": "CLASS",
        "properties": {
          "name": "OrderRoute",
          "fqn": "com.example.OrderRoute",
          "package": "com.example",
          "file": "src/main/java/com/example/OrderRoute.java",
          "interface": "false"
        }
      }
    ]
  }
}

This helps answer questions like:

• “What breaks if I rename this queue?”
• “Which routes depend on this transformation?”
• “What’s the blast radius of this change?”

The project-norms command reports project conventions plus an observed P75 route step count.

Query:

camel-kit graph project-norms

Output shape:

{
  "naming": {
    "routeIds": ["route:order-ingest", "route:order-process"],
    "detectedPattern": "kebab-case",
    "majorityPercentage": 0
  },
  "errorHandling": {
    "totalRoutes": 2,
    "routesWithErrorHandling": 1,
    "coverage": 50.0
  },
  "properties": {
    "patterns": ["orders.*"],
    "count": 3
  },
  "stepCounts": {
    "values": [4, 9],
    "p75": 9,
    "median": 9,
    "max": 9
  }
}

These are the nested sections returned by the raw command. When the graph is available, /camel-validate consumes them together with the dead-code report for project-aware validation.

MuleSoft projects use the same graph statistics schema:

Stats:

{
  "available": true,
  "nodes": 4,
  "edges": 3,
  "nodesByType": {
    "MULE_FLOW": 1,
    "MULE_PROCESSOR": 2,
    "MULE_ENDPOINT": 1
  }
}

Inspect the ordered nodes contained by a Mule flow with neighbors and the flow’s exact graph ID:

camel-kit graph neighbors mule-flow:order-processing-flow --direction out --edge-type MULE_FLOW_CONTAINS

The returned edges include their order property. To inspect called subflows instead:

camel-kit graph neighbors mule-flow:order-processing-flow --direction out --edge-type MULE_CALLS_SUBFLOW

route-flow is Camel-specific: it accepts an exact CAMEL_ROUTE ID such as route:order-processing-flow and emits only FROM, PROCESSOR, and TO steps.

The PropertyBindingParser understands Camel’s PropertyBindingSupport syntax — the engine that turns application.properties into a lightweight dependency injection container.

Bean instantiation — #class:com.foo.MyFactory creates an INSTANTIATES edge, tracking that a property creates an object at runtime.

Bean references — #bean:myService creates a REFERENCES_BEAN edge, linking a property to a named bean in the registry.

Auto-wiring — #autowired creates a REFERENCES_BEAN edge to a synthetic node, flagging that type-based bean discovery happens at runtime.

Type-based lookup — #type:com.foo.Type creates a REFERENCES_BEAN edge, finding a singleton bean by fully qualified class name.

Property cross-references — #property:otherKey creates a REFERENCES_PROPERTY edge linking one configuration property to another.

Convention-based detection — Recognizes framework-specific patterns:

• Spring Boot: spring.datasource.* → synthetic DataSource bean
• Quarkus: quarkus.datasource.* → synthetic DataSource bean
• Quarkus: quarkus.camel.* → marked as build-time properties (fixed after build)

Placeholder resolution — Scans endpoint URIs for {{key}} placeholders and creates CONFIGURES edges to the matching configuration properties.

Runtime detection — A shared RuntimeDetector utility identifies the project’s runtime (Spring Boot, Quarkus, Camel Main, Karaf) from Maven dependencies, enabling framework-specific analysis.

The migration-context command produces structured JSON from the local project graph. It performs a bidirectional, interface-aware BFS from one route, defaults to depth 3, and expands at most 50 related nodes. The result is focused local context, not a complete dependency map.

Usage:

camel-kit graph migration-context <routeId> [--depth N]

(the route ID without the route: prefix)

What it collects (using interface-aware BFS expansion):

Local graph context and later documentation lookup:

Camel-Kit has two complementary sources:

1. Project graph — structural knowledge about your project (routes, services, properties, dependencies)
2. Knowledge MCP — semantic knowledge about Camel itself (component docs, migration guides, CVEs, release notes)

The migration-context command reads only the project graph and performs no MCP call. If migration work needs Camel documentation, CVEs, or migration guides, the migration skill can later query the Knowledge MCP as a separate action, using components reported by the graph as lookup input.

The graph intelligence enhancements are inspired by the research paper Chinthareddy, “Reliable Graph-RAG for Codebases: AST-Derived Graphs vs LLM-Extracted Knowledge Graphs” (January 2026). The paper benchmarks three retrieval approaches for code understanding on Java codebases:

The DKB approach wins decisively: deterministic AST parsing is cheaper, faster, and more reliable than having an LLM extract a knowledge graph at indexing time. The key innovation is bidirectional traversal with interface-consumer expansion — when a class implements an interface, the graph traversal can discover consumers of that interface within its configured bounds.

What we adopted from the paper:

• Interface-consumer expansion — The core algorithm. When a USES_TYPE edge points to an interface, and concrete classes IMPLEMENTS that interface, the CrossLinker creates DEPENDS_ON_VIA_INTERFACE shortcut edges. The expandWithInterfaces() query method crosses these boundaries during BFS. This directly solves the paper’s key finding: vector search retrieves an implementation class but misses the controllers that depend on it through the interface.

• Bidirectional graph traversal — The expandWithInterfaces() method traverses both successors (downstream dependencies) and predecessors (upstream consumers), with direction-awareness. This is Algorithm 1 from the paper, adapted for our multi-layer graph.

• Deterministic over LLM-extracted — We use JavaParser (deterministic AST parsing) rather than asking an LLM to extract a knowledge graph. This aligns with the paper’s finding that deterministic indexing achieves near-complete chunk coverage (90-99%) while LLM extraction misses 20-35% of files due to stochastic skipping.

What we chose not to adopt:

• Tree-sitter for parsing — The paper uses Tree-sitter (a C-native parser with JNI bindings). For Camel-Kit’s Java AST parsing, we use JavaParser instead — it’s pure Java, already a dependency of camel-kit, and provides a richer typed API (getExtendedTypes(), getImplementedTypes(), getAnnotations()). Other graph parsers handle YAML, XML, Groovy, and related project formats, so adding Tree-sitter solely to the Java layer would add native-library complexity without a clear benefit.

• Single-graph RAG context assembly — The paper assembles context from one graph (the codebase). Camel-Kit keeps project structure and domain knowledge separate: migration-context reads the local project graph only, while a migration skill can later request Camel documentation, CVEs, or migration guides through the Knowledge MCP as a separate action.

• Closed-world type resolution — The paper’s DKB only tracks types within the project’s own source files. This works for the self-contained codebases the paper evaluates (Shopizer, ThingsBoard, OpenMRS) where most types are project-local. But in enterprise Camel projects, the majority of important types come from external dependencies — RouteBuilder, Exchange, Processor, ProducerTemplate, component-specific classes. We extended the graph with a POM-driven framework allowlist that also tracks dependencies on Apache Camel, Spring, Quarkus, and MuleSoft framework types when those frameworks are detected in the Maven POM.

• No dependency layer — The paper does not model Maven metadata or component-to-artifact mapping (from("kafka:...") only works if camel-kafka is in the POM). Camel-Kit’s PomParser records direct dependency metadata from pom.xml, and CrossLinker maps component usage to those artifacts — an area the graph already handled before adopting the DKB innovations.

• AST-only analysis — The paper treats code as the only input. We added two dimensions the paper doesn’t consider: property-based bean wiring (Camel’s PropertyBindingSupport syntax where application.properties instantiates and references beans) and configuration-to-code linking (tracking which properties are injected into which Java fields via @Value/@ConfigProperty). In Camel projects, properties are a load-bearing part of the architecture, not just metadata.