CAMEL-24223: Add camel_route_cost_estimate MCP tool

[oscerd]

Summary

Adds a new MCP tool camel_route_cost_estimate that estimates API costs for a Camel route based on its component usage patterns.

• 9 component cost profiles: Bedrock (per-token), Textract (per-page), S3/SQS/SNS/Kinesis (per-request), OpenAI (per-token), LangChain4j Chat/Embeddings (per-token), Docling (free)
• Per-execution cost breakdown: sorted by most expensive component first
• Projections: hourly, daily, and monthly cost estimates at configurable throughput
• Optimization tips: context-aware suggestions (e.g., "use Docling instead of Textract for text extraction")
• Configurable parameters: messages/hour, avg pages, avg input/output tokens

Example output structure

{
  "costBreakdown": [...],
  "projection": {"messagesPerHour": 100, "hourly": "$1.05", "daily": "$25.20", "monthly": "$756.00"},
  "summary": {"mostExpensiveComponent": "aws-bedrock"},
  "optimizationTips": [...]
}

Test plan

• 10 new tests covering AI pipelines, Textract routes, simple routes, cost projection, optimization tips, scheme extraction, defaults, combined processors
• All 310 existing MCP server tests pass (no regressions)

Claude Code on behalf of oscerd

🤖 Generated with Claude Code

[davsclaus]

Nice idea for an MCP tool — cost awareness is valuable for AI and cloud service routes.

Understanding the intent as a cloud/AI service cost estimation tool (not a general route cost calculator), the narrow component coverage is fine — the tool targets a specific set of pay-per-use services. A couple of suggestions to make that scope clearer and improve accuracy:

1. Tool name/description should reflect the scope: The current name camel_route_cost_estimate and description ("Estimate API costs for a Camel route") suggest general route costing. Consider renaming to something like camel_route_cloud_cost_estimate or updating the description to explicitly list the covered services (Bedrock, Textract, S3, SQS, SNS, Kinesis, OpenAI, LangChain4j, Docling) so users know what to expect.

2. Model-specific pricing: The Bedrock and langchain4j profiles hardcode Claude Sonnet 4 pricing, but the actual model matters a lot (Nova Lite vs Claude is 10-50x difference; langchain4j with Ollama is free). See inline comments for details.

This review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analyzers (SonarCloud).

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet]

A few technical observations on this new MCP tool, complementing davsclaus's existing review. See inline comments for details.

The most significant confirmed issues are: (1) package-private records violating the universal public record convention across all existing tool classes, risking Jackson serialization failures at runtime; (2) missing the standard try/catch exception handling pattern; and (3) the scheme extraction regex failing on XML routes despite the tool description claiming XML support, plus a subtle YAML parsing bug.

Regarding the langchain4j-chat hardcoded pricing — davsclaus already flagged this. +1 on that feedback.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[github-actions]

🧪 CI tested the following changed modules:

• dsl/camel-jbang/camel-jbang-mcp

---

🔬 Scalpel shadow comparison — Scalpel: 1 tested, 0 compile-only — current: 1 all tested

Maveniverse Scalpel detected 1 affected modules (current approach: 1).

Skip-tests mode would test 1 modules (1 direct + 0 downstream), skip tests for 0 (generated code, meta-modules)

Modules Scalpel would test (1)

• camel-jbang-mcp

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• dsl/camel-jbang/camel-jbang-mcp: 1 test(s) disabled on GitHub Actions

---

⚙️ View full build and test results

[oscerd]

Thank you both for the reviews. All findings addressed:

Structural fixes:

• ✅ All four result records now public record (matching convention across 16+ tool classes)
• ✅ Added standard try/catch exception handling pattern
• ✅ Added XML route support via XML_SCHEME_PATTERN regex — tool now correctly parses <from uri="scheme:..."/> syntax

Model-dependent pricing (davsclaus + gnodet):

• ✅ Bedrock display name now reads "AWS Bedrock (model-dependent, estimated as Claude Sonnet 4)" with a pricing note showing the range: Nova Lite ~$0.06/$0.24 vs Opus ~$15/$75
• ✅ LangChain4j Chat pricing note clarified: "free with Ollama/local models"
• Agreed that hardcoded pricing is a limitation — the disclaimer already notes costs are approximate. Externalizing pricing data to a config file is a good follow-up.

Test additions:

• ✅ New test for XML route scheme extraction

Claude Code on behalf of oscerd

[gnodet]

Re-review: three of four original findings were addressed (public records, try/catch, XML support). However, the YAML regex bug persists — from:\s+ matches across newlines, causing uri to be falsely captured as a scheme in multi-line YAML routes.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[oscerd]

Re-review finding addressed:

✅ Fixed YAML regex false scheme capture — replaced \s+ with [ \t]+ in from:/to:/toD: alternatives so the pattern only matches inline syntax (same line) and doesn't cross newlines. Multi-line from:\n uri: "scheme:..." now correctly matches only via the uri: alternative.

Test now asserts doesNotContain("uri") on extracted schemes.

Claude Code on behalf of oscerd

[gnodet]

All previously requested changes are now addressed across the three commits.

YAML regex fix verified: The three from:\s+, to:\s+, toD:\s+ alternatives now correctly use [ \t]+, which restricts matching to horizontal whitespace (space and tab), preventing the pattern from crossing newlines into a subsequent uri: key. The uri:\s* alternative correctly retains \s* since it is the terminal key that directly precedes the scheme value.

The new doesNotContain("uri") assertion in shouldExtractSchemesCorrectly directly validates the bug scenario: multi-line YAML from:\n uri: "scheme:..." no longer falsely captures uri as a scheme.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[davsclaus]

Nice work on this MCP tool — cost awareness for AI/cloud routes is genuinely useful. The technical issues from the prior round are all resolved; a few additional observations below.

Confirmed Issues (still outstanding from prior review)

1. Tool name implies general route costing, but scope is narrow (9 services)
The name camel_route_cost_estimate and description "Estimate API costs for a Camel route" suggest comprehensive coverage. In reality, only Bedrock, Textract, S3, SQS, SNS, Kinesis, OpenAI, LangChain4j, and Docling are covered. Renaming (e.g., camel_route_cloud_cost_estimate) or explicitly listing covered services in the @Tool description would set accurate expectations. (Aligns with davsclaus's finding #1)

2. Bedrock/LangChain4j estimates default to one of the most expensive models
The Bedrock profile uses Claude Sonnet 4 pricing ($3/$15 per MTok). A route using Nova Lite ($0.06/$0.24) would be overestimated by ~50x. The updated display name ("estimated as Claude Sonnet 4") helps, but users relying on the numeric output will get misleading projections. Same applies to langchain4j-chat which silently assumes the same expensive model. (Aligns with davsclaus's findings #2 and #3)

New Findings

3. Missing aws-bedrock-agent-runtime cost profile
Camel has three Bedrock schemes: aws-bedrock, aws-bedrock-agent, aws-bedrock-agent-runtime. The cost profiles only match aws-bedrock. Routes using aws-bedrock-agent-runtime (knowledge base retrieval, RAG, flow invocations) have per-session costs that won't be detected. At minimum, aws-bedrock-agent-runtime should have a cost profile entry.

4. No pricing data timestamp in output
The disclaimer says "approximate based on published AWS pricing" but doesn't say when the data was last verified. A simple field like pricingDataAsOf: "2025-Q2" in the result would help users gauge accuracy as the tool ages — a lightweight alternative to externalizing the full pricing model.

Questions

5. langchain4j-embeddings pricing consistency
This profile uses Titan Embed pricing ($0.02/MTok) but LangChain4j embeddings support any provider (including free local models). Should this follow the same "model-dependent" labeling as langchain4j-chat?

---

This review covers convention compliance and rules-based review. It does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analyzers (SonarCloud).

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of davsclaus

[oscerd]

All davsclaus suggestions applied:

1. ✅ @tool description now lists all covered services (Bedrock runtime + agent-runtime, Textract, S3, SQS, SNS, Kinesis, OpenAI, LangChain4j, Docling)
2. ✅ Added aws-bedrock-agent-runtime cost profile for RAG/Flows (model invocation + retrieval units)
3. ✅ Added pricingDataAsOf field to result ("2025-Q2")
4. ✅ LangChain4j embeddings note updated: "free with Ollama/local models"

Claude Code on behalf of oscerd

[gnodet]

Re-review (1 new commit since last approval)

Commit 3bd06cd correctly addresses all 4 of davsclaus's feedback items: (1) @tool description now lists all 11 covered services, (2) aws-bedrock-agent-runtime cost profile added with retrieval-unit pricing, (3) pricingDataAsOf field added to CostEstimateResult, (4) langchain4j-embeddings pricing note updated. The YAML regex fix ([ \t]+ instead of \s+) from the prior commit remains correctly in place. CI passes.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[gnodet]

All previously flagged issues from both review rounds (public records, try/catch pattern, YAML regex, XML support, aws-bedrock-agent-runtime profile, pricingDataAsOf, langchain4j-embeddings labeling) are confirmed addressed across the four commits. Clean implementation.

Two minor observations (non-blocking):

1. Locale-sensitive formatting: String.format("$%.6f", cost) in formatCost() uses the JVM default locale. In locales with comma decimal separators (e.g., French), this would produce $0,003000 instead of $0.003000. Since these are currency strings for MCP clients, String.format(Locale.ROOT, ...) would ensure consistent dot-separated decimals.

2. Test assertion precision: hasSizeGreaterThanOrEqualTo(2) on componentCosts could be hasSize(3) since the AI_PIPELINE_ROUTE has exactly 3 priced components (docling, aws-bedrock, aws2-s3). More precise assertions catch regressions more reliably.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[oscerd]

Note: #25052 had already merged (at 3bd06cd) when I pushed the review refinements referenced in the thread replies above, so those commits did not make it into this PR. I've opened them as a follow-up in #25167 (the Locale.ROOT formatting fix, the model-specific disclaimer, and the tighter tests). Apologies for the confusing thread references.

Claude Code on behalf of Andrea Cosentino (@oscerd).