voog-mcp

CLI and MCP server for Voog CMS — manage Liquid templates, pages, products, ecommerce settings, and redirects from your terminal or directly from Claude / any MCP client.

What is Voog?

Voog is a multilingual website builder and CMS with built-in ecommerce, used for content sites and small online stores. This package wraps its admin API so you can edit templates, pages, products, and redirects from your shell or an LLM agent.

Install

From PyPI:

pip install voog-mcp
# or, no install: uvx voog-mcp --help

Or directly from GitHub (latest unreleased main):

uvx --from git+https://github.com/runnel/voog-mcp.git voog --help

For development:

git clone https://github.com/runnel/voog-mcp
cd voog-mcp
python3.10 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

Configure

Run voog config init to interactively create the global config:

voog config init

This creates ~/.config/voog/voog.json with your tokens inline:

{
  "sites": {
    "mysite":   {"host": "mysite.com",   "api_key": "vk_..."},
    "client_a": {"host": "clienta.com",  "api_key": "vk_..."}
  },
  "default_site": "mysite"
}

Get a token from your Voog admin: Admin → API.

Shared / CI configs

If voog.json is checked into version control or shared across machines, keep the token out of the file by referencing an env var instead:

{
  "sites": {
    "client_a": {"host": "clienta.com", "api_key_env": "CLIENT_A_KEY"}
  }
}

Then put the token in ~/.config/voog/.env:

CLIENT_A_KEY=vk_...

Both forms can coexist per-site. When both api_key and api_key_env are set, the env-var wins if it's defined — so an inline value acts as a default that the deployment overrides.

Per-repo site selection

In a repo dedicated to one Voog site, drop a voog.json at the repo root to pin the site:

{"default_site": "mysite"}

The cwd-level voog.json deep-merges over the home config, with cwd winning per-key. Inside sites, the merge is per-site name — a cwd entry replaces the whole site definition (host + token), it does not merge individual fields. You can also redefine entire sites here (handy for client repos that should bring their own host/token without touching the home config):

{
  "sites": {
    "client_x": {"host": "clientx.com", "api_key": "vk_..."}
  },
  "default_site": "client_x"
}

Now voog pull / voog push from that directory always target the right site, even if the home default differs.

Note: voog-site.json from earlier versions still works but emits a DeprecationWarning. Replace it with voog.json containing {"default_site": "<name>"} for the same effect.

Use the CLI

voog --help                      # all commands
voog config list-sites           # show configured sites
voog --site mysite products      # list products on mysite
voog pull                        # download templates (uses cwd-level voog.json)
voog push layouts/Front\ page.tpl
voog redirects
voog config check                # verify all configured tokens
voog site-snapshot backup/       # full-site snapshot for diff/audit

Use as MCP server

Add to your Claude Code config (or any MCP client). The simplest setup uses the published PyPI package:

{
  "mcpServers": {
    "voog": {
      "command": "uvx",
      "args": ["voog-mcp"]
    }
  }
}

If you'd rather track unreleased main (e.g. for a fix that hasn't shipped yet), point uvx at the GitHub repo instead:

{
  "mcpServers": {
    "voog": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/runnel/voog-mcp.git", "voog-mcp"]
    }
  }
}

Every tool requires a site parameter. Start with voog_list_sites to discover what's configured:

voog_list_sites()
→ [{"name": "mysite", "host": "mysite.com"}, ...]

page_get(site="mysite", page_id=42)
→ {...}

Tools

Full endpoint coverage reference: docs/voog-mcp-endpoint-coverage.md

What's NOT supported

voog-mcp covers the surface area needed to manage content and a small ecommerce catalog. The following Voog API areas are intentionally out of scope for now — drop down to the generic voog_admin_api_call / voog_ecommerce_api_call passthrough tools when you need them:

• Order management, cart, and discount data

• Form definitions and form responses

• People / site_user admin

• Comments and visitor data

• Site favicons and bulk file imports — product image galleries are first-class via product_set_images, but other multipart uploads still go via passthrough

• Bulk product update / delete — bulk page show/hide is first-class via page_set_hidden(ids=[...]); product batch ops aren't covered yet

• Single-product deletion — product_delete is not yet wrapped (a v1.4 candidate); use passthrough in the meantime

• Site creation (voog-mcp targets existing sites)

If you need any of these, open an issue — or a PR.

License

MIT