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.

Related MCP server: drupal-mcp

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 content + ecommerce catalog management end-to-end as of v1.4. The following Voog API areas remain out of scope — drop down to the voog_admin_api_call / voog_ecommerce_api_call passthrough tools when you need them:

• Order mutation — orders_list / order_get are read-only typed tools (with PII stripping); creating / updating / cancelling orders goes via passthrough. Order writes carry finance / operations risk that a future release will design separately.

• Cart reads — cart_rules_* tools cover cart-rule CRUD, but reading individual cart sessions (/carts) is passthrough-only.

• element_definitions CRUD — element_definitions_list is wrapped; create / update / delete remain passthrough.

• People / site_user admin — full passthrough.

• Form definitions and form responses — passthrough.

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

• Site creation — voog-mcp targets existing sites.

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

License

MIT