Camel TUI and AI Agents

When an AI agent connects to the TUI via MCP, it gains the same level of visibility that you have — and can act on it. The agent can:

This starts an MCP server on localhost:8123 (configurable with --mcp-port). The server is bound to 127.0.0.1 only — it never listens on external interfaces.

When MCP is active, the TUI footer shows the connection status. Use F2 → MCP Info to see server details and MCP Log to view the tool call history.

Every running integration keeps a full status document in ~/.camel/<pid>-status.json, written once a second by camel-cli-connector. The tabs show a digest of it; the MCP server exposes the whole document as resources so an agent can fetch exactly the section it needs instead of paging through tabs:

resources/list enumerates the log, the document and its sections for every monitored integration, and resources/templates/list describes the URI shapes. The same data is available to the F8 AI panel (and as an MCP tool) through tui_get_status, which takes a section argument and returns that section only; pass sections to list what the document contains. Sections such as events can be large, so ask for the one you need.

Instead of talking to a model directly, the AI panel can hand the conversation to an external coding agent that speaks the Agent Client Protocol (ACP). The TUI starts the agent as a subprocess, gives it the TUI’s own MCP server, and shows the agent’s answer, tool calls and questions in the panel. The agent drives the TUI through the same tui_* tools that external MCP clients use, and can also read and edit your route sources with its own tools.

Any agent that speaks ACP works. Press Ctrl+P in the AI panel and pick one of the agents known to work, or acp:custom to run any other ACP agent:

The npx entries need Node.js 22 or newer (the Claude adapter requires it). The agent starts with your first question; the first start can take a while when npx has to download the adapter. Once the session is open the panel shows a two-row header with the agent’s coloured glyph, the agent’s name and version, the session id, the working directory and the number of commands it advertises. Use F2 → Settings to make an agent the default provider or to set the custom command (a plain command line split on whitespace, no quoting).

The MCP server is started automatically on a random localhost port when an agent needs it, so --mcp is not required. F2 → MCP Info shows the port and the tool calls the agent makes. Like the server started with --mcp, it is bound to 127.0.0.1 with no authentication, and it rejects requests that carry an Origin header (so a web page cannot reach it) or that are not JSON.

Permissions: calls to the TUI’s read-only tools (the tui_get_* tools, catalog documentation, expression evaluation, locate, validate) are approved without asking. So is camel_write_file while the write mode is confirm or live, because the TUI itself asks before the file is touched (the diff dialog or the live replay in the Source editor); with /write auto the permission popup is the only question and stays. A tool that changes anything else, such as camel_control, tui_send_message or tui_execute_sql, opens the same popup as any other request; answering "Always allow" makes it a one-time question per tool. For anything else the agent wants to do, such as editing a file with its own tools or running a command, a popup shows the agent’s options; Enter selects, Esc rejects that one call and lets the turn continue, and Ctrl+C cancels the whole turn. The preamble tells the agent to edit route sources through camel_write_file rather than its own file tools, so that you see the diff or watch the edit; when it still asks to edit a file directly, the popup says so and Esc sends it back to camel_write_file. "Always allow" choices are remembered by the agent for the session. The model, reasoning settings and any "always allow" rules are configured in the agent, not in the TUI; /model only reports the agent in use.

The agent’s own slash commands, for example Claude Code skills, appear as /agent:<name> in the / completion hints once the session is open; /agent: alone lists them. /agent:<name> … always reaches the agent, even when the name is also a panel command (/agent:clear clears the agent’s context, /clear the panel). Anything else starting with / that is not a panel command is sent to the agent as is.

The panel’s own /retry resends the last question (or /agent: command) to the agent. /context shows the agent, its session, working directory, MCP server and the size of the preamble instead of a model history, and /prompt shows that preamble, sent once per session ahead of the first prompt. /compact and /tools do not apply while an agent is selected: the agent manages its own history and reaches the camel-tui tools through the MCP server; the panel says so and points to /agent:compact when the agent offers that command.

If the agent asks for authentication and can sign you in itself, the TUI triggers that flow once; otherwise the panel shows the login command from the table above.

To connect Claude Code to the TUI, add the MCP server to your project configuration (.mcp.json in your project root):

The MCP server exposes two kinds of tools. The camel_ tools are the Camel authoring set shared with the camel mcp server (see Camel MCP Server): catalog documentation with the endpoint URI rules and the simple syntax (camel_catalog_doc, camel_catalog_find), source validation (camel_validate_source), reading and writing the source files (camel_get_files, camel_write_file), running an integration in dev mode and controlling it (camel_run, camel_control), its log and failed exchanges (camel_get_log, camel_get_errors), expression evaluation (camel_eval_expression) and error diagnosis (camel_error_diagnose). They are defined once in the Camel CLI, so an agent gets the same tools, names and answers through either server; in the TUI they work on the selected integration unless a directory or name argument says otherwise, and a write goes through the TUI’s confirm dialog or live replay. The tui_ tools are the ones only the TUI can offer, organized by purpose:

The TUI is for prototyping, human and AI together, so an agent (the built-in F8 panel or an external MCP client) can change the routes it is looking at. camel_get_files tells the agent where the sources are, which differs with how the integration was started (plain files, --source-dir, an example extracted to a temporary folder, or an exported project), and whether editing makes sense: devMode (changes are reloaded automatically), temporary (a copy that is lost when the integration stops) and an editing hint. camel_write_file then writes the complete new content of a file in that directory.

An integration started with --runtime=spring-boot or --runtime=quarkus runs from an exported Maven project, where the routes sit under src/main/resources/camel rather than next to a pom.xml. The listing understands that layout: it names the route and configuration files first, lists every file with its path relative to the project (build output skipped), and maps each running route to its file and line, so the agent reads the right file in one call instead of guessing names. File paths given to camel_get_files and camel_write_file are relative to that directory and may name a subdirectory.

Every write is confirmed in the TUI first: a dialog names the file, the directory and the size of the change (+3 -1 lines); press d to see the change as a unified diff, with removed lines on red and added lines on green like the Source tab’s F7 diff, and scroll it with the arrow keys; Enter, Esc or d returns to the summary. In the summary Enter applies the write and Esc rejects it, in which case the agent is told that the file is unchanged and not to retry. The dialog cannot be skipped by the agent on its own: confirm=false is honoured only after you switched to /write auto in the AI panel (the default /write confirm shows the dialog for every write, whatever the agent passes). Only plain file names in the source directory are accepted; the tool cannot write elsewhere, and there is no git integration, so the worst case is a wrong route file in a folder you are watching.

Before writing, an agent can check its content with camel_validate_source, which runs the same checks as the Source tab’s save: YAML routes against the Camel YAML DSL schema (a misspelled option such as logLevel instead of loggingLevel is reported) plus endpoint URIs and simple expressions, Java and XML routes read into the Camel model with the same endpoint and simple checks, and .properties files against the catalog of camel.* and Spring Boot options. camel_write_file runs that validation itself and refuses to write an invalid file, returning the errors instead, so a model fixes them rather than the user finding them in the log after the reload. Both tools are part of the core tool set, so local models (Ollama) get them as well.

Simple expressions get two more helpers, because they are what a small model gets wrong most often (functions belong inside the ${…​} placeholder, operators between placeholders: ${header.user} ?: 'Guest', not ${header.user ?: 'Guest'}). camel_catalog_doc for the simple language returns those syntax rules together with the catalog’s functions and operators (their count and names by group, or with optionsFilter the matching ones with parameters and examples), and docPage serves the operators, functions, OGNL and advanced documentation pages. camel_eval_expression evaluates an expression inside the running integration, like camel cmd eval, or locally when no integration is selected, and returns the value or the parser error, so the agent can try an expression before it answers or writes it. Component lookups get the same treatment for endpoint URIs: every endpoint option says whether it is part of the URI path or a query parameter, and the result spells out the URI rules for that component (its path options, the ?option=value&option=value form, the YAML uri plus parameters form, placeholders, RAW(), and that component options belong in application.properties). With endpoint the same tool checks a URI against the catalog, the way the YAML validator does on a write: unknown options with the closest real names, values that are not among the allowed ones, missing path parts, consumer options on a producer endpoint and the like, plus the options the URI uses with their documentation, so the agent can check an endpoint before it answers or writes it.

See Camel MCP Server for more about MCP and AI integration with Camel.