Graph Intelligence

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

Analysis Commands

Camel-Specific Commands

Context Commands

Output Commands

Originally, Camel-Kit had three MCP servers:

1. Camel MCP (catalog verification)
2. Knowledge MCP (semantic search)
3. Graph MCP (graph queries)

The Graph MCP was removed and replaced with a 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
• Reduced MCP count — From 3 to 2 (easier to deploy)

The graph is stored in an in-memory property graph (not persisted to disk). It’s rebuilt on each analysis via:

camel-kit graph parse --project /path/to/project

Why not persist?

• Freshness — Always reflects current code state
• Simplicity — No need to invalidate cache on file changes
• Speed — Parsing 175 nodes takes <1 second

For very large projects (1000+ routes), future versions may add persistence.

The impact command shows downstream effects of changing a node.

Query:

camel-kit graph impact --node "jms:queue:orders"

Output:

Impact of changing jms:queue:orders:
  1. route:order-processor (reads from this queue)
     ├─ bean:orderValidator (validates orders)
     ├─ route:notify-warehouse (sends notifications)
     └─ jms:queue:processed-orders (writes processed orders)
  
  2. route:order-monitor (also reads from this queue)
     └─ bean:metricsCollector (tracks order metrics)

Total affected routes: 2
Total affected beans: 2
Total downstream endpoints: 1

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 computes P75 statistics from the graph to establish project-specific validation thresholds.

Query:

camel-kit graph project-norms

Output:

{
  "routeComplexity": {
    "p50": 7,
    "p75": 12,
    "p90": 18,
    "p99": 25
  },
  "propertiesPerRoute": {
    "p50": 3,
    "p75": 5,
    "p90": 8,
    "p99": 12
  },
  "beansPerRoute": {
    "p50": 2,
    "p75": 4,
    "p90": 6,
    "p99": 10
  }
}

Usage:

When validating a new route, the agent can compare it against project norms:

## Validation Results
- Route complexity: 15 steps (above P75 of 12 — consider splitting)
- Properties used: 4 (within P75 of 5 — acceptable)
- Beans referenced: 7 (above P75 of 4 — review for reusability)

This enables context-aware validation — what’s “too complex” in one project might be normal in another.

On large MuleSoft projects, the graph can have 175+ nodes:

Stats:

Nodes: 178
  - Flow: 23
  - Processor: 68
  - Endpoint: 42
  - Bean: 31
  - Transformation: 14

Edges: 312
  - FLOWS_TO: 156
  - USES_BEAN: 89
  - TRANSFORMS_WITH: 34
  - WRITES_TO: 33

Route Flow Analysis:

camel-kit graph route-flow --route "order-processing-flow"

Output:

Route: order-processing-flow
  1. http:listener (POST /api/orders)
  2. json-to-object-transformer
  3. set-variable (customerId)
  4. flow-ref (validate-customer-subflow)
     ├─ db:select (customer lookup)
     └─ choice (customer exists?)
  5. set-payload (order confirmation)
  6. jms:publish (order.queue)
  7. on-error-propagate (error handler)

This graph-based flow tracing enables:

• Accurate migration (preserve exact flow semantics)
• Dependency discovery (which sub-flows are called?)
• Error handling analysis (what happens on failure?)

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 a structured JSON analysis of a route’s complete dependency chain — everything the migration skill needs to plan a route-by-route migration.

Usage:

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

(the route ID without the route: prefix)

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

Two-source bridge — graph meets knowledge:

Camel-Kit has two knowledge sources that the migration-context command bridges:

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)

Without the bridge, the LLM discovers components from the graph and separately searches docs for each one, manually correlating the two. With migration-context, the skill calls a single command to get the full structural context, then passes the component list directly to camel_docs_component_info and camel_docs_cve_search for targeted documentation lookup. One command replaces a multi-step manual correlation process.

This is more powerful than the paper’s single-graph approach — the paper assembles context from one graph (the codebase). Camel-Kit bridges project-specific structure with domain knowledge.

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 automatically discovers all consumers of that interface.

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 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). We use JavaParser instead — it’s pure Java, already a dependency of camel-kit, provides a richer typed API (getExtendedTypes(), getImplementedTypes(), getAnnotations()), and supports Java 1-25. Tree-sitter would add native library complexity for no additional benefit in our single-language (Java) context.

• Single-graph RAG context assembly — The paper assembles context from one graph (the codebase). Camel-Kit uses a two-source bridge: the project graph provides structural context (routes, services, properties), and the Knowledge MCP server provides domain knowledge (Camel documentation, CVEs, migration guides). The migration-context command bridges these by outputting a component list that the skill passes to the Knowledge MCP.

• 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 completely ignores Maven/Gradle dependency trees, framework auto-configuration (Spring Boot starters, Quarkus extensions), and component-to-artifact mapping (from("kafka:...") only works if camel-kafka is in the POM). Camel-Kit already handled this dimension through PomParser and CrossLinker before adopting the DKB innovations — an area where our graph was already more capable than the paper’s approach.

• 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.