Skip to main content

qsale-mcp

Model Context Protocol server for the QSale headless commerce platform.

Lets an LLM (Claude Code, Claude Desktop, Cursor, any MCP-compatible client) operate a QSale tenant through the same REST API the admin panel uses: catalog, content pages, navigation, segments, dictionaries, mailings, promotion triggers, redirects, and admin task triggers.

All write operations follow a propose → review → apply pattern: the model first stages the change and returns a before/after diff for you to read; nothing hits the backend until you say so.


Installation

Requires Python 3.11+.

pip install git+https://github.com/qsale-io/qsale-mcp-server.git

Or with uv:

uvx --from git+https://github.com/qsale-io/qsale-mcp-server.git qsale-mcp

Configuration

The server reads its configuration from environment variables — no flags, no config files.

Variable Required Default Purpose
QSALE_API_TOKEN yes — Employee API token
QSALE_COMPANY_ID yes — Company UUID (tenant scope)
QSALE_API_BASE no https://console.qsale.io Base URL of the QSale REST API
QSALE_CLIENT_TYPE no WEB Value of the X-QA-Client-Type header

Obtaining a token and a company id

  1. Sign in to your QSale admin panel.
  2. Open Settings → API tokens and create a new employee token. Save it somewhere safe — it is shown only once.
  3. The company UUID is visible in the admin URL or under Settings → Company.

Self-hosted installations override QSALE_API_BASE to point at their own console host (e.g. https://console.example.com).

Wiring into Claude Code

Add to your .mcp.json (or the global Claude Code MCP config):

{
  "mcpServers": {
    "qsale": {
      "command": "qsale-mcp",
      "env": {
        "QSALE_API_TOKEN": "your-token-here",
        "QSALE_COMPANY_ID": "00000000-0000-0000-0000-000000000000"
      }
    }
  }
}

For Claude Desktop, the configuration file lives at ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows) with the same mcpServers shape.

Available tools

The server registers ~100 tools, grouped by domain. See the source files or the model's tools/list output for the full list; below is the high level shape.

Read

Listing and detail tools for:

  • Product categories, products
  • Content pages
  • Navigation groups and items
  • URL redirects and redirect sites
  • Mail templates and template images
  • Promotion triggers and trigger categories
  • Dictionaries and dictionary items
  • Segments, segment properties, segment filters, segment property choices
  • Frontend settings

Write — propose / apply

Two-phase writes that stage the change in memory, return a diff, and only hit the backend when apply_* is called. Cover:

  • propose/apply_page_update
  • propose/apply_navigation_item_create + update
  • propose/apply_category_create + delete
  • propose/apply_mail_template_create + update
  • propose/apply_promotion_trigger_create
  • propose/apply_dictionary_create + delete
  • propose/apply_dictionary_item_create + delete
  • propose/apply_segment_create + delete
  • propose/apply_segment_property_create + update + delete
  • propose/apply_segment_property_choice_create + delete
  • propose/apply_segment_filter_create + update + delete
  • propose/apply_link_di_segment + unlink_di_segment
  • propose/apply_link_pc_segment + unlink_pc_segment

Admin task triggers

Schedule asynchronous backend tasks via the admin task endpoints:

  • propose/apply_run_update_all_dicts
  • propose/apply_run_update_dict
  • propose/apply_run_set_category_for_products

Direct writes (no two-phase)

Idempotent or low-impact operations are exposed as single calls:

  • create_redirect, update_redirect, create_redirect_site, update_redirect_site
  • update_category
  • update_frontend_setting_json, set_frontend_setting_file
  • create_mail_template_image

Batch

  • bulk_apply([proposal_ids]) — one approval covers N already-staged proposals of any kind. Stops on the first failure and returns per-proposal results.

How writes work

propose_* ──► in-memory Proposal{ id, kind, fields, before }  (no HTTP write)
                       │
                       ▼
            you read the diff in chat
                       │
                       ▼
apply_*  ──► REST POST/PATCH/DELETE on console.qsale.io

Proposals live only in process memory — restarting the MCP server discards them. This is intentional: a stale proposal should never be reused after a code reload.

Development

git clone https://github.com/qsale-io/qsale-mcp-server.git
cd qsale-mcp-server
python -m venv .venv && source .venv/bin/activate
pip install -e '.[dev]'
ruff check .
pytest

Versioning

This project follows Semantic Versioning. See CHANGELOG.md for release notes.

Security

Found a vulnerability? See SECURITY.md. Do not open a public issue for security reports.

License

Apache License 2.0 — see LICENSE.

Release files for qsale-mcp 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for qsale-mcp 0.2.1
File Size Uploaded
qsale_mcp-0.2.1.tar.gz 35.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for qsale-mcp 0.2.1
File Interpreter ABI Platform
qsale_mcp-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 70.6 kB

Release files / qsale_mcp-0.2.1.tar.gz

Download URL qsale_mcp-0.2.1.tar.gz
Size 35.8 kB
Tags Source
SHA-256 checksum
How to use checksums
e13d90747602821eef5300ab9c95b10e331c8f92c9dbd7f99ea13cf1214bd29a
BLAKE2b-256 checksum
How to use checksums
8f5442c1fe3277587e97efeb56fc34e3483caaf27fcfed1cdb0de53eda377369
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

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.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jun 5, 2026.

Transparency log

Release files / qsale_mcp-0.2.1-py3-none-any.whl

Download URL qsale_mcp-0.2.1-py3-none-any.whl
Size 34.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
7301b710cad3cede4e0329bb2ee8dfa1c583c0f27320cff8c45b89b53afc67ba
BLAKE2b-256 checksum
How to use checksums
5544c03914561e126d5f1326bde82ec0c95f70061d93042057d3f6d63b8c8bdc
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

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.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jun 5, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.1 This release

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page