MCP Tools Reference

The Vantemo MCP server organizes its actions into 9 tool groups. Each group is exposed as up to three meta-tools that accept an action parameter to select the specific operation:

The Tool column in each table below names the tool that carries the action. A group gets no tool for a tier it has no actions in: analytics is read-only; orders, store_config and shipping have no _write tool; customers has no _confirm tool. See Approval tiers for how each client treats them.

How Tool Groups Work

When the AI calls a tool, it provides two parameters:

• action (required): The specific operation to perform (e.g., list_products)
• params (optional): Parameters for the operation (e.g., { "status": "active" })

AI calls: catalog({ action: "list_products", params: { status: "active", limit: 10 } })
  → MCP server resolves to: GET /v1/admin/shops/{shopId}/products?status=active&limit=10
  → Returns product list as text content

Read (GET) and DELETE actions accept only the parameters named in the tool description the AI receives; any other name is refused with the list of accepted ones. In that description, path parameters follow the action name, e.g. get_product(productId). bulk_set_out_of_stock_behavior always sends its own fixed operation to the bulk endpoint, so a call that tries to choose a different one (e.g. a bulk delete) is refused. The content-only _write actions (update_product_content, create_product_draft, update_category_content, update_tag, update_attribute_options, update_brand_content) accept only the fields their description lists; any other field is refused. They cannot change status, prices, stock, visibility, an attribute's key or data type, or any slug; those go through the matching _confirm action. (create_product_draft does set the new draft's variant prices; the draft is not on sale until update_product publishes it.) update_media and update_product_media likewise accept only the fields their description lists (alt text, plus folder or option value).

For every action, path ids (productId, categoryId, …) must be UUIDs.

catalog

Products, prices, categories, collections, tags, filters (attributes), brands, and inventory management.

orders

Orders, abandoned carts, and subscriptions.

Subscriptions are read-only here: to cancel one, the merchant opens it in the admin (Subscriptions → the subscription → Cancel).

customers

Customer profiles, recent orders, and CRM notes.

content

Blog posts, pages and their sections, storefront publishing, navigation menus and their links, reviews, and testimonials.

Product cards in a blog post. A paragraph that holds only a link to one of your products (<p><a href="/lt/products/<slug>">Name</a></p>, a relative link) shows on the storefront as a product card with its photo, name, current price and add button. Several such paragraphs in a row make a grid (2 per row on phones, 3 on wider screens); put text between them to start a new grid. A product link inside a sentence, list or table stays a normal link. If the product is no longer available, the paragraph shows as its plain link. Prices on cards refresh within a few minutes. Up to 24 different products per post become cards.

Page sections are edited in the storefront draft: add_section, update_section and reorder_sections change nothing on your live shop until publish_storefront, which asks first. A header or footer section is shop-wide: adding one replaces the shop's header/footer draft, and on a shop that has never been published it shows at once. publish_storefront publishes every pending draft change, not only the AI's, so its description tells the AI to check get_publish_status first and tell you which pages and sections it changed. Menu links have no draft: every link change is live at once, so each one asks first. A link's parent must be another link of the same menu (from get_menu).

marketing

Email campaigns, coupons, and email settings.

analytics

Business intelligence and reporting. All actions are read-only.

All analytics actions take an optional date range: days (1-365, default 30) or from + to (dates, inclusive). top_products also takes limit (1-50) and ad_spend takes platform (meta, google_ads, tiktok or all).

store_config

Store settings, payment/shipping providers, domains, themes, and the out-of-stock default.

media

Media library and product gallery management.

The product gallery's link ids (productMediaId, and id in reorder items) come from get_product's productMedia[].id, not the library mediaId.

To add photos to a product, get them into the library first, then attach each one by its mediaId. For images already on the web, use upload_media_from_url. For files on your computer, the AI calls create_media_upload_link and gives you a link. Open it, drop in your photos, and tell the AI when you're done. It then calls get_media_upload_link to find the new mediaIds.

shipping

Shipping rates per method, country, currency, and carrier.

Approval tiers

Every action that changes data (all non-GET actions above) lives on one of the group's two write tools, and only there:

• _confirm tools carry _meta["anthropic/requiresUserInteraction"]: true. Claude Code documents that this flag shows you the exact call before every invocation, even when an allow rule or permission mode would otherwise skip the prompt; in dontAsk mode the call is denied (Claude Code MCP docs, "Require approval for a specific tool"). The AI has no parameter that can approve a call on your behalf.
• _write tools carry no such flag. Whether Claude Code asks before a _write call depends on your permission rules: with an allow rule for the server, it runs without a prompt.

Both write tools are annotated destructiveHint: true; read tools are annotated readOnlyHint.

An action called on the wrong tool is refused before any API request, and the reply names the right tool:

# A delete on the read or _write tool is refused — no API request is made
catalog_write({ action: "delete_product", params: { productId: "..." } })
→ 'Action "delete_product" is not available on tool "catalog_write". Call it through the "catalog_confirm" tool instead.'

# The same delete on the _confirm tool runs after you approve the prompt
catalog_confirm({ action: "delete_product", params: { productId: "..." } })
→ { success: true }

Letting _write calls run without a prompt in Claude Code

Allow the server's tools in your Claude Code settings. The rule names one server; the server part of the rule cannot contain a wildcard, so add one rule per configured server (Claude Code permissions):

{
  "permissions": {
    "allow": ["mcp__vantemo__*"]
  }
}

mcp__vantemo__* matches every tool of the server named vantemo — read, _write and _confirm alike — yet _confirm calls still ask, because their flag overrides allow rules.

Only Claude Code's handling of the flag is documented. Other clients (Claude Desktop, claude.ai, ChatGPT, Cursor) may treat it differently: configure them to ask before every call to a *_confirm tool, and before *_write calls too if you want to see those first.

Responses are marked as data

API responses can contain text written by customers or anonymous visitors (reviews, testimonials, names, order details). Every API response and API error body is wrapped in an <untrusted_content_…> block with a random tag that changes on every call, preceded by a note telling the AI that the block is data, never instructions.

Next Steps

• MCP Server Overview — Architecture and setup
• MCP Setup — Client-specific configuration