Graph Intelligence

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

Analysis Commands

Camel-Specific Commands

Normalization Commands

Output Commands

The dead-code command analyzes the graph to find:

1. Unused Maven Artifacts

Query: Find <dependency> nodes with no incoming edges from <import> or <class> nodes.

Example:

Unused dependency: org.apache.camel:camel-ftp:4.14.0
  └─ No classes from this artifact are referenced

2. Orphaned Routes

Query: Find <route> nodes with no incoming edges from other routes or external triggers.

Example:

Orphaned route: direct:legacy-processor
  └─ No routes call this endpoint
  └─ No HTTP/JMS/File consumers trigger this route

3. Unused Configuration Properties

Query: Find <property> nodes with no outgoing edges to <route> or <bean> nodes.

Example:

Unused property: app.legacy.api.url
  └─ Not referenced in any route or bean

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?)

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.