The model decides what. A tested route decides how.

Why agents need an action layer

The same refund across orders, payments, shipping and email, with the agent calling each API itself, or calling one Cameleer route.

Tested end to end: resolved (200), the same call again runs nothing (200 duplicate), bad arguments named (400), not delivered yet (409), over the limit waits for a person (202), carrier down and the refund rolled back (502). The route and the walkthrough.

What Cameleer guarantees, whatever the model does

Each row is enforced by the server on every call, not left to a prompt or to each tool's author, and each is backed by a test or by the field test with Claude.

Prove which server and tools an agent is talking to

Next release: run Cameleer in a confidential VM (Intel TDX, AMD SEV-SNP or a dstack CVM) and an MCP client can ask, in the handshake, for hardware evidence of the exact routes, configuration and tools the server runs, bound to the client's nonce and to the session's TLS connection. A model showing that evidence is not checking it; the client program checks the binding and the hardware signature. How it works, and what it does not prove yet.

More than an MCP server

MCP is how agents reach the action layer. Around it, Cameleer does the rest of the work an agent needs, in the same process.

An existing route becomes an MCP tool by changing one line

Keep the route's steps. Replace the line it starts from with an ai-tool URI that names the tool and its arguments, then run it with --mcp. The route still does the work with any of Cameleer's about 230 components; the server adds the checks on every call.

- 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:
        - setBody:
            simple: '{"orderId": "${header.orderId}", "status": "shipped"}'

# the CLI
cameleer run orders.camel.yaml --mcp          # http://localhost:8080/mcp
cameleer run orders.camel.yaml --mcp-stdio    # for Claude Desktop

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

# the Rust crate (cameleer-main)
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 route that other routes or a REST endpoint also call keeps its direct: start; add a three-line ai-tool route in front of it that does to: direct:lookup-order. Apache Camel's ai-tool, ai-resource and camel.server.mcp-* names work unchanged. Reference: Cameleer MCP guide, MCP server.

Or serve existing routes with no edits at all

--mcp-expose serves routes you already run as MCP tools without touching the route files. It is on the main branch now and ships in the next release.

cameleer run orders.camel.yaml --mcp-expose rest:*
cameleer run orders.camel.yaml --mcp-expose direct:lookup-*
cameleer run orders.camel.yaml --mcp-stdio --mcp-expose rest:*,route:billing-*

Five tests in crates/cameleer-main/tests/mcp_expose.rs cover it, including the real binary over stdio. Routes added after start-up (dev reload) are not picked up yet. Reference: Expose existing routes without editing them.

Both an MCP server and an MCP client

Most products are one or the other. Cameleer is both, with the same checks on both sides, so it can serve your tools, use other servers' tools, and stand between your agents and every server they use.

Use cases, with the requests people typed

Each page shows real requests from the field test against the shop example (a whole back office in one YAML file), the tool calls Claude made, the answer, and the tested route behind it.

Where it runs, and why each matters

Commands for each, all run against an image built from the source: Where to run it.

How it compares

One tool answering a JSON document, on three identical cloud machines (4 dedicated vCPUs each, 64 client connections).

Every Cameleer call in the benchmark went through the whole envelope, which costs about 6 µs per call on those machines. Camel has the larger ecosystem and its own strengths: Apache Camel's MCP server vs Cameleer. A hand-wired agent against a route on a four-system refund: direct tool calls vs Cameleer. Raw data: benchmarks. MuleSoft, Boomi, Workato, WSO2, TIBCO, IBM and Azure Logic Apps as MCP platforms: enterprise MCP platforms compared.

Tested with real requests through Claude

40 requests a shop's staff would type ran through Claude and the official MCP Python client against the shop example. Each run was graded on the tool calls made, the database afterwards and a separate judge of the answer.

The four Opus misses were slips in the answer, not wrong actions. The first run passed 25 of 36 requests; every failure led to a fix in Cameleer or in the example: Ask Claude about your business.

Try the shop in Claude Desktop

The shop example is 19 tools, three policies and two prompts in one YAML file. Run it over HTTP, or let Claude Desktop start it (configuration in the example's README).

git clone https://github.com/pmsudhi/cameleer && cd cameleer/examples/agents/mcp-shop
cameleer run shop.camel.yaml --properties application.properties
# or, with nothing installed but Docker:
docker run --rm -p 18190:18190 -v "$PWD:/routes:ro" pmsudhi/cameleer run /routes/shop.camel.yaml \
  --properties /routes/application.properties --prop acme.dir=/routes --prop camel.server.host=0.0.0.0