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
- Sign in to your QSale admin panel.
- Open Settings → API tokens and create a new employee token. Save it somewhere safe — it is shown only once.
- 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_updatepropose/apply_navigation_item_create + updatepropose/apply_category_create + deletepropose/apply_mail_template_create + updatepropose/apply_promotion_trigger_createpropose/apply_dictionary_create + deletepropose/apply_dictionary_item_create + deletepropose/apply_segment_create + deletepropose/apply_segment_property_create + update + deletepropose/apply_segment_property_choice_create + deletepropose/apply_segment_filter_create + update + deletepropose/apply_link_di_segment + unlink_di_segmentpropose/apply_link_pc_segment + unlink_pc_segment
Admin task triggers
Schedule asynchronous backend tasks via the admin task endpoints:
propose/apply_run_update_all_dictspropose/apply_run_update_dictpropose/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_siteupdate_categoryupdate_frontend_setting_json,set_frontend_setting_filecreate_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)
| File | Size | Uploaded | |
|---|---|---|---|
| qsale_mcp-0.2.1.tar.gz | 35.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| 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 logRelease 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