Integration routes as MCP tools

A tool, a resource and a prompt

Three components make what an MCP client sees: ai-tool (an action the model can take), ai-resource (a document it can read) and ai-prompt (a prompt template the user can pick). A tool's arguments arrive as headers and the route's body becomes the result.

# mcp-server.camel.yaml
- route:
    id: lookup-order
    from:
      uri: ai-tool:lookup_order
      parameters:
        description: Look up an order by id
        tags: support
        parameter.orderId: string
        parameter.orderId.description: The order id, such as EU-4411
        parameter.orderId.required: true
        readOnlyHint: true
      steps:
        - setBody:
            simple: '{"orderId": "${header.orderId}", "status": "shipped", "carrier": "DHL"}'
- route:
    id: refund-policy
    from:
      uri: ai-resource:refund-policy
      parameters:
        uri: docs://refund-policy
        description: When and how much we refund
        mimeType: text/markdown
        tags: support
      steps:
        - setBody:
            constant: "# Refund policy\n\nDamaged items are refunded in full within 30 days."
- route:
    id: support-reply
    from:
      uri: ai-prompt:support-reply
      parameters:
        description: Draft a reply to a customer
        tags: support
        argument.question.description: The customer's question
        argument.question.required: true
        argument.tone.values: friendly,formal
      steps:
        - setBody:
            simple: "Write a ${header.tone} reply to this customer question, citing our refund policy: ${header.question}"

The file is examples/agents/mcp-server.camel.yaml. In a real tool the setBody is a call to your order system, a database query or a queue: any of the about 230 components, with the route's own error handling and retries.

Serve it

cameleer run mcp-server.camel.yaml --mcp
# MCP endpoint: http://localhost:8080/mcp

{
  "mcpServers": {
    "orders": {
      "command": "cameleer",
      "args": ["run", "/path/to/mcp-server.camel.yaml", "--mcp-stdio"]
    }
  }
}

On the command line --mcp and --mcp-stdio expose every tool, resource and prompt. In a configuration file nothing is exposed until you choose: camel.server.mcp-enabled=true and camel.server.mcp-tags=support. All properties: MCP server configuration.

Docker, serverless, the edge: the same tools wherever they run

One route file serves MCP from the binary, the container, your own Rust program, a serverless platform or a gateway next to the machines. Every command below is in the MCP server guide.

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

{
  "mcpServers": {
    "orders": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "/path/to/tools:/routes:ro",
               "pmsudhi/cameleer", "run", "/routes/mcp-server.camel.yaml",
               "--mcp-stdio"]
    }
  }
}

What happens on every call

Every call, from an MCP client, the agent step, a model component or a route, goes through the same envelope, in this order. In Apache Camel the tool hints are advisory; here they set the defaults of these checks.

Pinning: a tool's definition hash covers its name, description, schemas and hints. A route that changes a tool but keeps its version fails to start, so a tool cannot change under a client that already trusts it (camel.ai.manifest keeps the hashes across restarts). Details: ai-tool, a call step by step.

Approvals and operators

From inside a tool route

A long tool can report progress and log lines to the client, ask the client's user a question or ask the client's model, in both protocol eras: ai-tool:x?operation=progress, log, elicit and sample. A route can also return images, audio or embedded resources by setting CamelAiToolContent.

One gateway in front of other MCP servers

Cameleer is also an MCP client. It imports the tools of remote servers into its registry, where they run through the same envelope, and its own server can serve them again next to your tools.

camel.ai.mcp.github.url=https://mcp.example.com/github
camel.ai.mcp.github.bearerToken={{env:GITHUB_TOKEN}}
camel.ai.mcp.files.command=files-server

camel.server.mcp-enabled=true
camel.server.mcp-tags=mcp:*,support
camel.server.mcp-auth=jwt
camel.server.mcp-jwt-jwks-url=https://login.example.com/.well-known/jwks.json
camel.server.mcp-resource-url=https://tools.example.com/mcp

The agent step uses remote tools with tools: mcp:github, and a route calls one without a model with to: mcp:github/create_issue. Details: MCP client and gateway and the mcp component.

How it is checked

• The official conformance suite (@modelcontextprotocol/conformance 0.1.16, pinned and checksum-verified) passes every scenario: 39 of 39 for 2025-11-25 and 26 of 26 for 2025-06-18. The suite predates 2026-07-28, so that era is covered by the hermetic tests.
• Hermetic tests drive both eras over real HTTP and stdio connections, including approvals, subscriptions, authentication, the gateway and a tool that changes upstream.
• An end-to-end test starts the real cameleer binary as a stdio MCP server and has an agent step call one of its tools.

Measured on three identical cloud machines: 41,620 tool calls per second in MCP sessions in 53 MB, against 22,458 in 317 MB for Apache Camel's MCP server and 1,536 for a server written on the official TypeScript SDK; a tool call through the envelope costs 3 to 6 µs (the comparison).

Run it

Clone the examples, then point an MCP client at the endpoint or the stdio command.

git clone https://github.com/pmsudhi/cameleer && cd cameleer/examples/agents
cameleer run mcp-server.camel.yaml --mcp
# or, without installing anything:
docker run --rm -p 8080:8080 -v "$PWD:/routes:ro" pmsudhi/cameleer run /routes/mcp-server.camel.yaml --mcp