get-products
Get a paginated list of products. Authenticated via bearer token. Supports filtering by SKU or tag and optionally includes variants.
EACH ROW IS LEAN BY DEFAULT: id, sku, title, price, inventory, imageUrl, tags. fields IS THE NORMAL WAY TO READ PRODUCTS: name exactly the top-level fields you need, and description, images (the whole gallery — imageUrl is its first picture), customAttributes, brand, categoryId and the rest come back only when named. The list replaces the default rather than adding to it. For one whole product use get-product.
Every row carries its tags in tags, and its attribute values in customAttributes when asked for, so there is no separate call needed to see how a product is tagged or what attributes it holds. A product in a mature catalog can carry a hundred or more inherited attribute rows; leaving customAttributes out of fields skips that join entirely rather than just hiding it, so a sweep like "find products with no brand" costs a fraction of a full read. Same for tags, variants and inventory.
To find products by something other than SKU or tag — brand, quantity, or "has no tags at all" — pass a filters tree, or the id of a saved segment as segmentId (get-segments lists them). Either beats paging the whole catalog and filtering client-side.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "get-products"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Filter by SKU | |
| page | No | ||
| tags | No | Only return products carrying at least one of these tag names (case-insensitive). Combines with tagIds as OR. | |
| limit | No | ||
| fields | No | Top-level fields to return; `id` is always included. Omitted means the lean default (id, sku, title, price, inventory, imageUrl, tags); a list replaces that default, so name everything you need. Omitting `customAttributes` or `tags` skips their join, so this is a real cost saving and not just a smaller payload. | |
| tagIds | No | Only return products carrying at least one of these tag IDs (tag IDs come back in each record's `tags` field) | |
| filters | No | Filter tree, same shape a segment stores — a condition is { property, type, option, value }. This is how you filter by anything other than SKU or tag: brand, price, warehouses.on_hand_quantity, or { property: "tags.tag_id", type: "array", option: "is none" } for "has no tags at all". Far cheaper than paging the catalog and filtering client-side. Full operator and field reference: usage.filters from get-action-catalog | |
| segmentId | No | Filter to products covered by a segment (from the get-segments tool) | |
| withVariants | No | Include each product's variants. Adds `variants` to the default row; with `fields`, list `variants` there as well. |