Ghost-Agent: A Docker MCP Execution Engine for LLM Tool-Call Chains

What Ghost-Agent Solves and Who It Is For

Running an LLM agent against a set of tools typically requires writing glue code to parse the model's output, map it to the right function, handle errors and retries, and present a consistent interface whether the caller is a terminal, a web client, or a bot. Ghost-Agent packages that plumbing into a Docker container so a developer can start routing natural-language commands to real tools without building the execution layer first.

The project is aimed at developers who want to build agents on top of Solana blockchain data. The README positions it as a backend execution layer for on-chain and off-chain AI workflows, citing DeFi data queries, balance lookups, and token metadata as its current Solana capabilities. Teams building crypto portfolio assistants, DeFi monitoring bots, or Solana-aware Telegram bots are the stated target audience.

A secondary audience is anyone building a Docker-based agent pipeline who needs a starting point with a modular tool system. The Tool Registry is the component that makes the project extensible: new tools are added under a plugins/tools directory without touching the execution logic.

The Planner-Executor-Registry Architecture

Ghost-Agent separates agent work into three distinct layers, and understanding where each lives clarifies what the project does and does not handle.

The Planner acts as the intent recognition stage. It takes a natural-language input from the CLI, Telegram, or the HTTP API and calls an LLM to produce a structured execution plan. That plan is a JSON document describing a sequence of tool calls, ordered by dependency. The Planner does not execute anything; it only decides what should happen and in what order.

The Executor receives the plan and runs it. It walks the tool-call chain step by step, handles retries when a tool fails, logs each step, and collects outputs. Where steps are independent, the README states the Executor can run them in parallel, though the documentation does not specify how that concurrency is controlled.

The Tool Registry is the catalog that connects plan steps to actual code. Each entry declares a tool's name, module path, function signature, and parameter schema. Adding a new tool means registering it in the catalog, not modifying the Executor. This is the mechanism the README uses to support a growing list of data sources: currently DexScreener and Binance for market data, CryptoPanic for news, and several Solana-specific calls.

Connectors are the entry points that feed input to the Planner. The CLI connector is aimed at local testing. The Telegram connector turns the agent into a chat bot. The HTTP API connector exposes a REST endpoint so external services can POST a command and receive a structured result.

One significant caveat: the primary language listed for the repository is Shell, and the package.json in the repository points to a different project named ralph-claude-code. The README describes a Python 3.11 and Docker architecture, but the actual top-level files include Shell scripts named ralph_import.sh, ralph_loop.sh, and ralph_monitor.sh. The mismatch between what the README documents and what the repository contains is a real gap that a potential user must investigate before treating the described architecture as the deployed one.

Installing and Running Ghost-Agent with Docker

The README skips any step involving cloning the repository or building from source. The intended install path is pulling the Docker image and pointing it at a local .env file.

Start by creating a working directory and writing the required environment file:

mkdir mcp-execution-env
cd mcp-execution-env

Then create the .env file with the two required variables:

cat <<EOF > .env
MCP_LANG=EN
OPENAI_API_KEY=sk-xxxxxxxxxx
EOF

MCP_LANG accepts EN or ZH; OPENAI_API_KEY must be a valid OpenAI API key. Replace the placeholder value with your actual key before proceeding.

Pull the image:

docker pull coreonmcp/coreon-mcp-execution-engine

To start in interactive CLI mode, where you type a command and the agent processes it in the terminal:

docker run --rm -it --env-file .env coreonmcp/coreon-mcp-execution-engine start cli

The CLI mode is the quickest way to test whether the Planner correctly interprets a natural-language instruction and whether the Executor runs the expected tools.

To expose an HTTP API on port 8080 for integration with other services:

docker run --rm -it --env-file .env -p 8080:8080 coreonmcp/coreon-mcp-execution-engine start server

For Telegram bot mode, which requires adding the bot token to the environment file in addition to the OpenAI key, the command changes the start argument to telegram-bot. The README does not document the specific Telegram environment variable name for the bot token, so that detail requires checking the upstream repository or the Docker image's own documentation.

The project has no GitHub releases. The Docker image tag coreonmcp/coreon-mcp-execution-engine corresponds to what the README calls the main branch, but the repository itself and the published image belong to different accounts, which adds a further layer of uncertainty about provenance.

Solana Integration: Scope and Roadmap Items

Ghost-Agent's Solana integration covers three current capabilities: querying wallet balances, fetching token metadata, and pulling DeFi data through DexScreener. These are all read operations. No write operations, transaction signing, or swap execution are documented as working today.

The README lists several planned additions: natural-language swaps on PancakeSwap, AI wallet assistants, and on-chain security monitoring for Solana users. All three are presented as mid-term roadmap items, not current features. The headline Solana feature in the README, autonomous agent payments via the MCP payment signal protocol, is labeled as coming soon.

A separate branch named coreon-mcp is called out as the integration branch for the MCP payment signal protocol. The README links to a different repository, pav-linto/Archon-Terminal, for tracking that integration, which means the payment feature is being developed in a parallel codebase rather than in the main CryptoDmitry/Ghost-Agent repository.

For a developer whose workflow depends on anything beyond read-only Solana queries, the current feature set will not cover it. The documentation is honest about the gap: autonomous payments are marked coming soon and the security monitoring is framed as future vision.

Limitations and Cases Where Ghost-Agent Is the Wrong Tool

The dependency on OpenAI's API is the most immediate constraint. Ghost-Agent as documented requires OPENAI_API_KEY in the environment file. There is no documented path for substituting a local model, an Anthropic model, or any other OpenAI-compatible provider. Teams operating in environments where sending data to a third-party API is not permitted cannot use the project as described.

The absence of GitHub releases means there is no stable version to pin. A production deployment pulling coreonmcp/coreon-mcp-execution-engine:latest could receive breaking changes without notice. The project explicitly describes itself as beta.

The security audit conducted by Armors Labs and listed as PASSED covers the Coreon MCP Execution Engine codebase. The audit report is linked from the README, but the link points to a different GitHub account. For a team evaluating this project for a security-sensitive application, the scope of that audit relative to the actual CryptoDmitry/Ghost-Agent code is unclear.

The mismatch between the README's description of a Python-and-Docker system and the Shell-based codebase in the repository is a fundamental issue for any developer who wants to understand what they are running. The README appears to document a related but distinct project. Until the code and documentation are reconciled, treating Ghost-Agent as production-ready would require auditing the actual Docker image independently.

Ghost-Agent Compared to LangChain

LangChain is a Python and JavaScript library that provides primitives for building LLM application pipelines, including agents, tool executors, and memory. Unlike Ghost-Agent's Docker container approach, LangChain is a library you import into your own application code. You instantiate models, define tools, and wire the chain manually, giving you fine-grained control over each step and the ability to swap any component.

Ghost-Agent's approach is the opposite: the container ships everything. The Planner, Executor, and Tool Registry are already wired together, and deployment is a single docker run command. The trade-off is opacity. You adopt the project's architectural decisions, its tool set, and its dependency on OpenAI. You cannot easily insert a custom retry policy, change the plan serialization format, or audit what happens between the Planner's output and the Executor's first tool call without examining the container internals.

LangChain's ecosystem is broad and well-documented, with integrations for dozens of LLM providers and tool types. It is the right choice for teams who need flexibility, multi-provider support, or a community of existing plugins. Ghost-Agent is the right choice for a team that wants a Docker drop-in specifically aimed at Solana agent workflows and is willing to work with a beta-stage codebase.

Maintenance and License

The last push to CryptoDmitry/Ghost-Agent was on 2026-08-25. The repository is not archived and shows no sign of being abandoned. The MIT license permits commercial use, modification, and distribution without restriction beyond attribution.

The project has no GitHub releases and no versioned tags visible in the main repository. The associated Docker image is published by a separate account named coreonmcp. For upgrade management, there is no documented process beyond pulling a new image tag. The README changelog is maintained through branch descriptions and inline notes rather than a structured release log.

Given the beta status and the gap between the documented architecture and the observed codebase, a team integrating Ghost-Agent into any non-trivial system would need to establish its own process for tracking upstream changes, since the project does not yet provide one.

Editorial conclusion

Ghost-Agent suits developers who want a pre-packaged Docker container for running MCP tool-call chains without wiring a planner, executor, and registry from scratch. It is the wrong choice for teams that need local model support, multi-chain blockchain coverage beyond Solana queries, or a system backed by stable releases. Before adopting it, verify that the Docker image coreonmcp/coreon-mcp-execution-engine is current, that the README content matches the code in the branch you pull, and that the autonomous payment feature your workflow depends on is not still marked as coming soon.

Frequently asked questions

Official sources

1. CryptoDmitry/Ghost-Agent on GitHub
2. Issues
3. License: MIT
4. README