Cameleer MCP: the action layer for AI agents

The model decides what; a tested route decides how. Cameleer sits between AI agents and your systems: agents call it over MCP from Claude, IDE assistants and agent frameworks, each action runs as a route, and the server enforces what a model can't be trusted with: arguments checked, retries run once, risky actions approved by a person, slow calls cancelled, every call audited. In a field test with 40 real requests, Claude Opus 5.5 completed 196 of 200 runs correctly, and none ran an action twice, broke a rule or ran a risky call without a yes.

Cargo feature: ai · Examples: examples/agents/mcp-shop, examples/agents/mcp-gateway

This page is the map: why agents need an action layer, how Cameleer's MCP server works, where it runs, how it compares, and one page per use case with the requests people typed, what happened, and the tested route behind it.

Why agents need an action layer

Agents are good at deciding and bad at doing things exactly once, within the rules, with a record of who allowed what. Cameleer enforces those parts on every call, whatever the model does:

On a refund across four systems, an agent calling each API directly needs 4 tool calls and 5 model turns and can refund twice, leave half-done work or choose the amount; through one Cameleer route it is 1 tool call and 2 model turns, run once, rolled back on failure, with the amount taken from the order (direct tool calls vs Cameleer).

MCP is how agents reach this layer. Around it, Cameleer also feeds events to models (Kafka, MQTT, webhooks, files), calls 23 model providers with retries and fallbacks (model providers), routes on the model's answer, and runs agents itself with the agent step.

In one minute

The Model Context Protocol (MCP) is how AI clients find and call tools. With Cameleer, a tool is a route:

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

cameleer run tools.camel.yaml --mcp          # Streamable HTTP on http://localhost:8080/mcp
cameleer run tools.camel.yaml --mcp-stdio    # for a client that starts the server itself

Existing routes become tools without editing them. cameleer run orders.camel.yaml --mcp-expose rest:* serves every REST DSL operation as a tool with typed arguments taken from its documented parameters; direct:* and route:* patterns select other routes. Reads (GET, HEAD) are read-only tools, and every other exposed tool needs approval by default (how).

Or make a route a tool by changing one line, when you want to name the tool and its arguments yourself. Keep its steps and replace the line it starts from with an ai-tool URI that names the tool and its arguments (examples/agents/route-to-mcp-tool.camel.yaml):

 - route:
     id: order-lookup
     from:
-      uri: direct:lookup-order
+      uri: "ai-tool:lookup_order?description=Look up an order by id&parameter.orderId=string&parameter.orderId.required=true&readOnlyHint=true"
       steps:

Then one command serves it, from the CLI, Docker or your own Rust program:

cameleer run orders.camel.yaml --mcp
docker run --rm -p 8080:8080 -v "$PWD:/routes:ro" pmsudhi/cameleer run /routes/orders.camel.yaml --mcp

main.set_property("camel.server.mcp-enabled", "true");
b.from("ai-tool:lookup_order?description=Look up an order by id&parameter.orderId=string&parameter.orderId.required=true&readOnlyHint=true")
    .set_body(simple(r#"{"orderId": "${header.orderId}"}"#));

A test (an_existing_route_becomes_a_tool_by_changing_one_line in crates/cameleer-main/tests/mcp_main.rs) checks that the example differs from the original route in that one line and serves the tool, from YAML and from the Rust DSL. A route that other routes or a REST endpoint also call keeps its direct: start, with a three-line ai-tool route in front of it that does to: direct:lookup-order.

Cameleer is both an MCP server and an MCP client. It serves your routes to agents, and it imports other MCP servers' tools for routes and models to use, or serves them again as a gateway with the same checks.

In a real tool the setBody is a query, an API call, a queue: any of Cameleer's about 230 components, with the route's own error handling and retries. The fastest way to see what that means is the shop example: a whole back office in one YAML file that you can ask questions in Claude Desktop.

How it works

1. Routes become tools, resources and prompts. ai-tool, ai-resource and ai-prompt endpoints use Apache Camel's names and options; the server uses Camel's camel.server.mcp-* properties (MCP server).
2. Every call goes through one envelope, in this order: kill switch, authorization, JSON Schema 2020-12 argument checks, rate limit, circuit breaker, approval, deduplication, compensation, a timeout that cancels the route, output checks and redaction, a hash-chained audit record. The model never decides whether these apply (ai-tool).
3. Both protocol eras on one endpoint: the stateless 2026-07-28 era and the 2025-11-25, 2025-06-18 and 2025-03-26 versions with sessions. Over Streamable HTTP and stdio.
4. Approvals and questions go to the person. A risky call shows the user an approval form (input_required or elicitation/create), or waits for an operator; a tool route can ask the user a question in the middle of a call.
5. Cameleer is also a client. It imports the tools of other MCP servers into the same envelope and serves them again, so one endpoint can front many servers (MCP client and gateway).

The official MCP conformance suite passes all 39 scenarios for 2025-11-25 and all 26 for 2025-06-18.

Use cases

Each page shows requests a shop's staff typed into Claude, the tool calls Claude made, what came back, and the route that made it safe. The requests come from the field test; the routes are the shop example and run in Cameleer's test suite (crates/cameleer-main/tests/mcp_shop.rs).

Where it runs, and why each matters

Commands and settings for each: Where to run it.

How it compares

Measured on three identical cloud machines (4 dedicated vCPUs each, 64 client connections), one tool answering a JSON document (benchmarks):

Each Cameleer call in that run went through the whole envelope (schema check, rate-limit and breaker bookkeeping, an audit record); the envelope costs about 6 µs per call on that Xeon.

The Camel column follows Camel's documentation as summarised in Apache Camel's MCP server vs Cameleer; direct tool calls vs Cameleer compares a hand-wired agent with a route on a refund across four systems.

What a real field test found

40 requests a shop's staff would type ran through Claude and the official MCP Python client against the shop example, five times each with Claude Opus 5.5:

Each run is graded on the tool calls made, the database afterwards (for example, that no refund was written) and a separate judge comparing the answer with the tool results. The four Opus misses were wording slips, not wrong actions. The first run passed 25 of 36 requests; the fixes it led to are in what the test changed.

Reference

• MCP server: every property, protocol versions, approvals, authentication
• MCP client and gateway: importing other servers' tools
• ai-tool, ai-resource, ai-prompt
• The agent step: Cameleer as the agent, with the same tools
• Ask Claude about your business: the shop example and the field test

Found a problem?

If something on this page doesn't match what Cameleer does, please open an issue, or fork the repository, fix it, add a test, run cargo test --workspace and open a pull request.