mcp-host-agent
The host-level deployment & supervision agent for the MCP Worker platform.
Install once per host, manage every local Worker service end to end — deployment, health polling, heartbeat aggregation, crash self-healing, and Git-service-driven continuous delivery.
What this is
mcp-host-agent is a system CLI you install — not a Python project you write.
The thing you build is a Worker (a small
mcp-worker-sdk repo exposing
/health /tools /execute /meta). This CLI points at your Worker's Git repo and
does the clone / install / run / supervise / heal for you.
So no “worker directory structure” lives here — that belongs to
mcp-worker-sdk.
Built on
| Layer | Technology |
|---|---|
| Runtime | Python 3.10+ |
| Control plane (HTTP API) | FastAPI + uvicorn |
| Worker deployment | subprocess — git / pip / systemctl / launchctl |
| Config & validation | pydantic + PyYAML |
| Hub / Worker polling | httpx |
| Shared protocol | mcp-worker-protocol |
Why
Deploying MCP Workers by hand means writing the same git clone + pip install + systemctl restart + heartbeat + self-healing glue every time — multiplied by the
number of Workers and hosts you manage. mcp-host-agent turns that glue into a
single, declarative, docker-style CLI.
- One agent per host manages N Worker services.
- Coolify-like Git UX — private/public Git repos plus push-to-deploy webhooks.
- Rich three-tier health — status, queue backpressure, and latency/reliability profile flow up to the Hub for smarter scheduling.
- Self-healing — process-level restart, rollback to the previous commit, and structured escalation.
Install
The recommended path is a dedicated virtualenv (Debian/Ubuntu system Python
is PEP 668 “externally managed” and won't allow pip install):
sudo apt-get update && sudo apt-get install -y python3-venv python3-full
python3 -m venv /opt/mavis-venv
/opt/mavis-venv/bin/pip install --upgrade mcp-host-agent
ln -sf /opt/mavis-venv/bin/mcp-host-agent /usr/local/bin/mcp-host-agent
mcp-host-agent --version
Requires Python 3.10+. The agent's own service unit is generated with
{sys.executable} -m mcp_host_agent.cli ..., so it works from a venv, pipx,
or system Python without a PATH symlink.
Quick start
# 1. Generate the config (--config defaults to /etc/mavis/agent.yaml).
mcp-host-agent config init --hub-url https://hub.example.com --agent-id agent-sandbox
# 2. Add a worker (writes back to agent.yaml atomically).
mcp-host-agent worker add --name demo-worker --repo https://git.example.com/owner/demo-worker.git --port 9101
# 3. Install as a system service: auto start-on-boot + crash-restart.
sudo mcp-host-agent deploy install-service
# 4. That's it — the agent is now running as a daemon.
Verify:
curl http://127.0.0.1:9200/health
curl http://127.0.0.1:9200/meta
curl -H "X-Agent-Token: <agent-token>" http://127.0.0.1:9200/api/v1/agent/status
deploy install-serviceis the recommended production path (same philosophy asdocker/tailscale: install → auto-enabled → boot + crash resilient). If you just want to run it in the foreground for a test, usemcp-host-agent deploy run.
Adding more Workers
# Add a second worker, then hot-reload (no restart).
mcp-host-agent worker add --name neo4j-worker --repo https://git.example.com/owner/worker-neo4j.git --port 9102
mcp-host-agent deploy reload
--configdefaults to/etc/mavis/agent.yaml, sodeploy run/reload/status/worker lscan all be invoked without repeating the path.
Features
| Capability | Description |
|---|---|
| Deployment | git clone/pull, pip install, and systemd/launchd service management |
| System service | deploy install-service auto-enables and makes the agent boot/crash resilient |
| Supervision | Polls each Worker's /health + /meta, derives status, aggregates heartbeat |
| Self-healing | Decision tree: restart → rollback (git checkout HEAD~1) → give up + escalate |
| Rich telemetry | Forwards degraded_reason, avg/p95 latency, estimated_wait_ms, success_rate through Heartbeat.health |
| Git CD | Gitea and GitHub webhook push-to-deploy with HMAC signature verification |
| Private repos | Credentials via git_username + git_token_env (token stays out of YAML) or the host credential helper |
| Docker-style CLI | config / worker / deploy grouped subcommands |
| Hot reload | deploy reload sends SIGHUP; newly added Workers bootstrap without a restart |
Configuration
The agent is driven by a single agent.yaml (default /etc/mavis/agent.yaml):
hub_url: "https://hub.example.com"
agent_id: "agent-sandbox"
agent_token: "<agent-token>" # protect control endpoints
webhook_secret: "<webhook-secret>" # Gitea/GitHub webhook signature
platform: linux # linux | macos
agent_port: 9200 # control API port
workers:
- name: sandbox-worker
repo: "https://git.example.com/owner/worker-sandbox.git"
branch: main
port: 9101
git_username: "will" # private repo username
git_token_env: "GITEA_TOKEN" # token read from env, never written to YAML
# self-healing defaults (overridable by Worker /meta.recovery)
auto_restart: true
max_restart: 3
restart_interval: 5
fail_threshold: 3
graceful_timeout: 10
- name: neo4j-worker
repo: "https://git.example.com/owner/worker-neo4j.git"
port: 9102
The token referenced by
git_token_envis read from the environment at clone time and is not persisted to disk. If bothgit_usernameandgit_token_envare omitted, the host's own Git credential helper (or SSH config) is used.
What the agent does vs. does not do
mcp-host-agent deploys, supervises, and reports heartbeat only. It does not
register Worker tools with the Hub — tool registration is the Hub/mcpstore's
job. Each Worker's port in agent.yaml is the single source of truth: the
agent passes it to the Worker as the MCP_WORKER_PORT environment variable so
there's no drift between two places. (This requires mcp-worker-sdk to honour
MCP_WORKER_PORT; without it, the Worker falls back to its own run(port=...).)
Set up push-to-deploy (Gitea / GitHub)
-
Point your webhook at the agent:
- Payload URL:
http://<host-agent-ip>:9200/webhook - Content type:
application/json - Secret: the same value as
webhook_secretinagent.yaml
- Payload URL:
-
Gitea — enable “Push” events.
-
GitHub — enable “Just the push event”.
Every push with a valid signature triggers git pull → pip install → service restart and reports commit status back.
Supported platforms
| Platform | Runner | System service |
|---|---|---|
| Linux | systemd | mavis-agent.service |
| macOS | launchd | mavis.agent.plist |
Windows is not supported in v1. The agent manages native host processes (systemd/launchd). Containers such as Docker/K3s pods are self-healed by their own orchestrators, not by the agent.
Programmatic API
from mcp_host_agent import (
AgentConfig,
WorkerConfig,
WorkerManager,
Supervisor,
create_app,
)
config = AgentConfig(
hub_url="https://hub.example.com",
agent_id="agent-sandbox",
jwt_token="<jwt>",
workers=[WorkerConfig(name="demo", repo="https://git.example.com/o/demo.git", port=9101)],
)
manager = WorkerManager(config)
manager.ensure_cloned(config.workers[0])
manager.install_deps(config.workers[0])
manager.start(config.workers[0])
supervisor = Supervisor(config, manager)
supervisor.poll_all()
heartbeats = supervisor.build_heartbeats("2026-08-16T00:00:00+00:00")
app = create_app(config, supervisor, manager) # FastAPI control plane
See the full integration guide at
docs/mcp-host-agent/DELIVERY_INTEGRATION.md
and the CLI reference at
docs/mcp-host-agent/CLI_REFERENCE.md.
Development
pip install -e ".[dev]"
pytest # unit + integration + contract + compatibility
ruff check .
License
Metadata
Release files for mcp-host-agent 1.1.5
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| mcp_host_agent-1.1.5.tar.gz | 32.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mcp_host_agent-1.1.5-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 65.4 kB
Release files / mcp_host_agent-1.1.5.tar.gz
| Download URL | mcp_host_agent-1.1.5.tar.gz |
|---|---|
| Size | 32.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
750acee834b3d127f5424b81734437d35f445e8dd584c70cb9e566d05f53fffc
|
|
BLAKE2b-256 checksum How to use checksums |
e4827d8dffa266f81814d266149231bb6992f0aea9add5c8b007eadf4238f583
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.6
|
Release files / mcp_host_agent-1.1.5-py3-none-any.whl
| Download URL | mcp_host_agent-1.1.5-py3-none-any.whl |
|---|---|
| Size | 33.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
27cd7bbcba452d3f01a0a98c7a615e6b7384d4576beedee26a52f47f6ffad501
|
|
BLAKE2b-256 checksum How to use checksums |
2ee6c3434ba3cfbf71690546160ac3fcccc929c3a998a5d1bf2969864252690f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.6
|
Security for mcp-host-agent 1.1.5
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.