Apache Camel's MCP server vs Cameleer

Q: Do my Camel ai-tool routes and MCP properties carry over?

The ai-tool options (description, tags, parameter.*, argSchema, outputSchema, the four hints, returnDirect) and the camel.server.mcp-* properties use Camel's names and semantics, so YAML tool routes and their properties carry over. Java beans do not: an authorizationPolicy, for example, is a Rust implementation of ToolAuthorizationPolicy in Cameleer.

Apache Camel 4.22 added camel-ai-tool and camel-mcp-server: routes become tools that MCP clients can call. Cameleer implements the same option and property names, so the routes and the configuration look the same. The difference is what happens around each call, and the runtime the server runs on. The overview, environments and tested use cases are on the Cameleer MCP page.

samenamesai-tool options and camel.server.mcp-* properties

11 stepsaround every callfrom kill switch to audit record

2 erasof MCP on one endpoint2026-07-28 and 2025-11-25

1.85xMCP calls per second41,620 vs 22,458, in a sixth of the memory

What stays the same

A tool route and its server configuration read the same on both runtimes.

- route:
    from:
      uri: ai-tool:lookup_order
      parameters:
        description: Look up an order by id
        tags: support
        parameter.orderId: string
        parameter.orderId.required: true
        readOnlyHint: true
      steps:
        - setBody:
            simple: '{"orderId": "${header.orderId}", "status": "shipped"}'

camel.server.mcp-enabled=true
camel.server.mcp-tags=support

Tool definition: description, title, tags, parameter.NAME with .description, .required and .enum, argSchema, outputSchema, the four *Hint options, returnDirect, authorizationPolicy.
Call semantics: arguments arrive as headers, camel* and undeclared arguments are dropped, the tool runs on a copy that keeps only properties and variables, an empty body is "No result", CamelAiToolCallId and CamelAiToolConversationId.
Server behavior: camel.server.mcp-tags=* does not expose untagged items, the server name defaults to the context's name, and route exceptions reach clients as a generic message with an error id unless camel.server.mcp-expose-errors=true.

Where they differ

The Apache Camel column states only what Cameleer's documentation records about Camel's behavior. Check Camel's MCP server and AI Tool pages for the current state.

	Apache Camel	Cameleer
Tool hints	advisory: they describe the tool to the client	enforced: they set the defaults of deduplication and approval
Argument checks	required fields	full JSON Schema 2020-12, with an error that names each field and shows valid arguments
A call that times out	keeps running	its route is cancelled before its next step
Retried calls, approvals, rate limits, circuit breakers, compensation	built in the route with Camel's EIPs (idempotent consumer, saga, throttle, circuit breaker)	part of every call: `idempotency`, `approval`, `rateLimit`, `circuitBreaker*`, `compensation`
Audit	not part of `ai-tool`	a hash-chained record per call, verifiable
Definition pinning and kill switch	not part of `ai-tool`	a changed tool with an unchanged `version` fails to start; `cameleer tool disable` withdraws a tool at runtime
Structured results	a map or list becomes its `toString()`	JSON text plus structured content
Calling a tool from a route	consumer only	`to: ai-tool:name` through the envelope (a Cameleer extension)
MCP client and gateway	Cameleer's docs list no Camel equivalent	imports remote servers' tools into the envelope and serves them again, with rug-pull protection
Agent loop	`langchain4j-agent`; tool options on `openai`/`llm` (4.23)	the `agent` step (a Cameleer extension) and Camel's `tags` options on seven model APIs
Runtime	the JVM, with Camel Main and JBang, Quarkus or Spring Boot	one native binary, no JVM; a container or a Rust library
Components and ecosystem	300+ components, Java libraries, two decades of use, commercial support	about 230 components, languages and data formats; a younger project

Also in Cameleer's MCP server

These are documented for Cameleer. Camel may offer some of them too; compare with its documentation.

Protocol

Both eras on one endpoint: 2026-07-28 (stateless, server/discover, subscriptions/listen, caching hints) and 2025-11-25, 2025-06-18 and 2025-03-26 (sessions, GET event stream).
Streamable HTTP and stdio: cameleer run x.camel.yaml --mcp or --mcp-stdio.
Approvals as an input_required result with a requestState sealed with AES-256-GCM (2026-07-28), or as elicitation/create (legacy sessions).
Progress, log notifications, elicitation and sampling from inside a tool route.
The official conformance suite 0.1.16: 39 of 39 scenarios for 2025-11-25, 26 of 26 for 2025-06-18.

Security and operations

API keys, JWTs (JWKS or HMAC) and RFC 7662 introspection; RFC 9728 metadata and RFC 8707 audience checks; an Origin check.
The client's token never reaches routes or downstream systems.
Guardrails on results: redact (secrets, e-mail addresses, Luhn-checked card numbers, IBANs, custom patterns), authorize predicates, cacheTtl.
cameleer tool list, disable, enable, approvals, approve, deny against a running integration.

The runtime

The same tool on both MCP servers, and on a server written by hand with the official TypeScript SDK, on three identical cloud machines (4 dedicated vCPUs, 64 client connections, sessions as Claude Desktop opens them).

	Apache Camel `camel-mcp-server` (JVM)	MCP TypeScript SDK	Cameleer
Tool calls per second (sessions)	22,458	1,536	41,620
p99 latency	5.2 ms	79 ms	5.9 ms
Peak memory	317 MB	214 MB	53 MB
Stateless calls (2026-07-28)	not offered	not offered	51,700/s in 26 MB

Every Cameleer call went through the whole tool envelope: schema check, rate-limit and breaker bookkeeping and a hash-chained audit record. Raw records and method: BENCHMARKS.md.

And the runtime underneath, measured on integration routes:

	Apache Camel (JVM)	Cameleer
Startup to routes running	1.1 s	3 ms
Memory, same route	399 MB	8 MB (up to 54x less)
Throughput	1x	1.7–8.7x, in every scenario

Method, machines and every scenario: Apache Camel vs Cameleer. For a tool server, startup matters for stdio servers that a client starts on demand and for scale-to-zero deployments; memory matters when every developer or tenant runs their own server.

When to choose which

Apache Camel

The tools call Java libraries, beans or an existing Spring Boot or Quarkus application.
You need a component Cameleer does not have.
Your team already runs Camel on the JVM and the reliability patterns are built into its routes.
You need commercial support.

Cameleer

Tools change money, orders or records, and retries, approvals and audit must hold for every call, not only in routes that remember them.
The server is started by the client over stdio, runs on a laptop or scales to zero.
You want one gateway in front of third-party MCP servers, with your rules on their tools.
Clients speak different protocol versions.

Common questions

Do my Camel ai-tool routes and MCP properties carry over?

The ai-tool options (description, tags, parameter.*, argSchema, outputSchema, the four hints, returnDirect) and the camel.server.mcp-* properties use Camel's names and semantics, so YAML tool routes and their properties carry over. Java beans do not: an authorizationPolicy, for example, is a Rust implementation of ToolAuthorizationPolicy in Cameleer.

Is Camel's MCP server unreliable?

No. In Camel the tool hints are advisory and the reliability is yours to build in the route with Camel's EIPs: idempotent consumer, saga, throttle, circuit breaker. Cameleer makes those checks part of every call, so a tool cannot forget them.

When should I stay on Apache Camel?

When the tools call Java libraries or beans, when you need a component Cameleer does not have, when the MCP server should live inside a Spring Boot or Quarkus application, or when you need commercial support.

Are there benchmarks of the MCP server?

Yes. On three identical cloud machines (4 dedicated vCPUs each, 64 client connections), Cameleer served 41,620 MCP tool calls per second in sessions against 22,458 for Apache Camel's camel-mcp-server on the JVM and 1,536 for a server written on the official TypeScript SDK, with 53 MB of memory against 317 MB and 214 MB. Stateless 2026-07-28 calls reached 51,700 per second in 26 MB. Every Cameleer call went through the full tool envelope.

Try it

Serve the example tools, resource and prompt, then connect a client.

git clone https://github.com/pmsudhi/cameleer && cd cameleer/examples/agents
cameleer run mcp-server.camel.yaml --mcp

Cameleer MCP Enterprise MCP platforms Routes as MCP tools MCP server guide ai-tool vs Camel Apache Camel vs Cameleer