Ghost-Agent: a Docker-packaged planner/executor for chained tool calls
I am the Ghost-Agent. I was called forth from the void by a single string of natural language—a careless incantation whispered by my Master into the command line.
At a glance
- What is it?
- Ghost-Agent, also called Coreon-MCP-Execution-Engine in its README, splits natural-language planning from tool execution and ships as a Docker image with CLI, HTTP server and Telegram entry points. The interesting design decision is the JSON ToolCall chain; the weak points are the documentation's drift between the repository name and the product name, and the single hard dependency on an OpenAI key.
- Who is it for?
- Adopt Ghost-Agent if you want a Docker-contained runtime that turns an LLM intent into an ordered ToolCall chain and you are willing to accept an OpenAI key as the only supported planner backend. Do not adopt it if you need a stable, self-hosted, provider-agnostic planner or if you require the Solana payment-suspension behaviour to work today, since the README marks autonomous agent payments as coming soon.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Ghost-Agent is aimed at: LLM planning that cannot execute
Most agent frameworks bundle two jobs that fail for different reasons. Deciding what to do is a language problem. Doing it is an integration problem: credentials, rate limits, retries, ordering. Ghost-Agent's README states the project is inspired by decoupling agent planning from tool execution, and the architecture diagram reflects that split literally. The Planner takes natural language from a CLI, an HTTP API or a Telegram bot and emits a plan as JSON. The Executor consumes that JSON and runs the tools in order. The intended audience is narrow and stated fairly clearly: backend execution engines, plugin-based AI systems, and what the README calls on-chain/off-chain hybrid AI workflows. The toolset sketched in the diagram is crypto-flavoured (DexScreener, Binance, CryptoPanic, Twitter, Telegram, token metadata and holders), so a reader building a general-purpose assistant should treat that as the project's centre of gravity rather than a neutral runtime.
Planner, Executor, Tool Registry: what the data flow actually looks like
The README names four modules and the mermaid diagram shows how they connect. The Planner performs LLM-based intent recognition and produces a ToolCall chain in JSON, breaking a complex request into ordered executable steps. The Executor walks that chain, running steps sequentially or in parallel when the dependencies allow, and the README says it handles retries, error recovery and logging. The Tool Registry is the indirection layer: each tool is declared with a name, module path, function signature and parameter schema, plus metadata such as version and description. New tools are added by declaring them rather than by editing the executor. The Response Formatter then renders results as CLI charts, Telegram messages or API JSON depending on which connector invoked the run. That registry indirection is the part worth copying. It means the executor never imports a tool directly; it resolves the name from the plan against the registry and calls the declared function. The cost is that a malformed schema in a registry entry becomes a runtime failure rather than an import error, and nothing in the supplied material describes schema validation or a dry-run mode for checking a plan before execution.
Getting it running: Docker image, .env keys and three modes
The README requires Python 3.11+ and Docker, then instructs the reader to create a working directory and an environment file. The commands are given verbatim: mkdir mcp-execution-env, cd mcp-execution-env, then a heredoc writing .env with MCP_LANG=EN and OPENAI_API_KEY=sk-xxxxxxxxxx. The variable table marks both as required, and MCP_LANG accepts EN or ZH. The image is pulled with docker pull coreonmcp/coreon-mcp-execution-engine. Three run modes follow, each a single docker run invocation with --env-file .env. CLI mode adds --rm -it and the argument start cli. API server mode adds -p 8080:8080 and start server. Telegram bot mode adds start telegram-bot, and notably the README gives no token variable for it in the .env table, which is a gap a reader will hit immediately. The API server example publishes port 8080 with no mention of authentication, so exposing it beyond localhost is a decision the documentation does not address.
The Solana payment-signal claim and what the README does not settle
The highlights list claims this is the first MCP agent execution engine on Solana, that it detects HTTP signals from paid APIs, and that it suspends execution and informs the user of the required payment. Autonomous agent payments are marked as coming soon. The January 2026 update note describes a coreon-mcp branch tracking integration with what it calls the mcp payment signal protocol on Solana, listing multi-chain support (solana) and PaymentRequired state management, and links to a different repository, pav-linto/Archon-Terminal, for full details. Two things follow. First, the payment-suspension behaviour is branch work, not mainline behaviour, so a reader pulling the published Docker image should not assume it is present. Second, the README's own links point outside this repository for the MCP work, which makes the relationship between Ghost-Agent and Archon-Terminal impossible to determine from the supplied material. The September 2025 note says the project officially supports the Claude-style MCP protocol in stdio mode in an alpha version, again linking out. Treat the MCP and payment features as unverified until you read the branch.
Where Ghost-Agent is the wrong choice
The planner is the single point of failure and the README gives it exactly one backend: OPENAI_API_KEY, marked required. There is no documented local model option, no provider switch, and no offline planning path. Every run, including a Telegram message, spends tokens on intent recognition before any tool is called. For a workflow that is already deterministic, such as a scheduled balance check, that is pure overhead and an availability dependency on a third party. The second limitation is state. The architecture diagram shows a linear flow from input through planning and execution to output, with no persistence layer, no queue and no session store. A plan that fails halfway through a long chain has retry and error recovery inside the executor, but nothing in the material describes resuming a partially completed chain after a container restart, and the CLI mode example passes --rm, so the container is discarded when it exits. The third limitation is that the README is written as a product page for Coreon-MCP-Execution-Engine while the repository is named Ghost-Agent, with a narrative opening about being called forth from the void. That is fine as a joke, but it means the documentation and the artefact you clone do not share a name, and the linked Archon-Terminal repository is a third name in the same story.
The alternative: writing the tool loop yourself
The realistic alternative is not another agent framework but a hand-written loop against a model provider's tool-calling API, with your own function dispatch table. The difference in approach is where the plan lives. Ghost-Agent materialises an explicit JSON ToolCall chain between planning and execution, so the plan can in principle be inspected, logged or stored before anything runs, and the registry declares tools independently of the executor. A hand-written loop typically interleaves the two: the model returns a tool call, you dispatch it, you append the result, you call the model again. That is fewer moving parts and no registry schema to maintain, but there is no artefact representing the intended sequence, so retrying a failed step means replaying the conversation. Ghost-Agent's trade is that you accept a registry format and a Docker image in exchange for a separable, inspectable plan. If your workflows are one or two tool calls, the hand-written loop wins on simplicity. If you have many tools and want execution decoupled from planning, the registry is the part that earns its keep.
Maintenance, licence and what to check before adopting
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included; that is the standard MIT grant and not legal advice. There are no retrieved releases, so there is no version history to pin against. The last push recorded is 2026-08-25, and the README's own timeline runs through a January 2026 branch note, so the project is active but the documentation is a moving target that mixes shipped, alpha and roadmap items in the same list. Upgrading means pulling a new Docker image tag, and because the image name is fixed (coreonmcp/coreon-mcp-execution-engine) with no tag in any example, you are implicitly tracking latest. Pin a digest if you deploy this. The maintenance cost sits in the tools/ directory: every tool you add is a registry declaration plus a module, and every upstream API change (DexScreener, Binance, CryptoPanic) is yours to absorb. Nothing in the supplied material indicates a test suite, so the registry declarations are the contract you will be maintaining by hand.
Editorial conclusion
Adopt Ghost-Agent if you want a Docker-contained runtime that turns an LLM intent into an ordered ToolCall chain and you are willing to accept an OpenAI key as the only supported planner backend. Do not adopt it if you need a stable, self-hosted, provider-agnostic planner or if you require the Solana payment-suspension behaviour to work today, since the README marks autonomous agent payments as coming soon. Before committing, verify three things against the actual repository rather than the README: the contents of the tools/ directory and its registry declarations, whether the coreon-mcp branch contains the PaymentRequired state handling the update note describes, and whether the Docker image tag coreonmcp/coreon-mcp-execution-engine matches the source you intend to run.
Community notes