Skip to main content
Glama
lukabudik

alza-mcp

by lukabudik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search Alza products

search_products
Read-onlyIdempotent

Find products in the Alza.cz catalog by keyword to compare options, check prices, stock, and ratings, and filter by category, brand, or price.

Instructions

Search the Alza.cz catalog by keyword. Use this for product discovery — finding what's available, comparing options, or starting research. Returns a list with product code, name, price, stock (from the card's purchase CTA), and rating. To get full details for one product, follow up with get_product. Sorting: Alza's search page ignores server-side sort, so price-asc / price-desc / rating scan up to ~72 top-ranked candidates (3 pages) and sort them client-side — candidatesScanned reports how many were scanned; for an absolute price floor also pass max_price. in_stock: true keeps only products with a live purchase CTA. Brand/attribute filtering: call list_category_filters({category_id}) for real ids, then pass producer_ids and/or filters with category_id. This switches to Alza's own filtered category page, so query is ignored and results match what the website shows; a filter Alza doesn't honour returns an error rather than unfiltered results. Slider facets (screen size, refresh rate, brightness, weight, …) filter by {param_id, min?, max?} range; the applied ranges come back in appliedRanges. min_screen_inches/max_screen_inches use the category's real diagonal slider when category_id is given, and a product-name size heuristic otherwise. For attributes Alza has no facet for, compare shortlisted candidates with get_product's params. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-indexed result page (follows Alza's rendered pagination). Only pages Alza actually renders are reachable — a page beyond the rendered set returns no results rather than repeating page 1. Paginating this way does not change which page the sweep scans (sorting still scans from page 1).
sortNoSort order, default 'relevance'. Alza's search page ignores server-side sort parameters, so price (asc/desc) and rating sorts gather candidates from up to 3 result pages (~72 items — the top of Alza's relevance ranking) and sort them client-side; the response's `candidatesScanned` says how many candidates were scanned. 'newest' is best-effort (Alza's newest-sort is client-side JS, so it returns relevance order). For an absolute price floor, also pass `max_price` and/or narrow `category_id`.
limitNoMaximum number of results to return. Default 20, max 50.
queryYesSearch keywords. Required. Example: 'iPhone 15 Pro', 'PlayStation 5', 'gaming mouse Logitech'.
filtersNoAttribute filter selections from `list_category_filters` (`filterable: true` groups only; never guess ids). Requires `category_id`. Combines with `producer_ids`. Two forms: `{param_id, value_id}` for Checkbox groups (`filterMode: "value"`), and `{param_id, min?, max?}` for Slider groups (`filterMode: "range"` — screen size, refresh rate, brightness, weight, port counts, …; at least one bound; units are the group's `values[].value`; live-verified 2026-10-06). The ranges Alza actually applied come back in `appliedRanges`. If Alza doesn't honour a filter, the call errors instead of returning unfiltered results.
in_stockNoIf true, keep only products purchasable right now (card shows a 'Do košíku'/'Vybrat variantu' purchase CTA; cards with a 'Hlídat' watch button are excluded). Derived from the search card's CTA — for real delivery dates use `get_product`.
max_priceNoMaximum price in the locale's currency.
min_priceNoMinimum price in the locale's currency.
category_idNoRestrict the search to a specific category id. Use list_categories to discover ids.
producer_idsNoFilter by brand id(s) — get real ids from `list_category_filters`'s `brands`. Requires `category_id`. Works in every category.
max_screen_inchesNoMaximum screen diagonal in inches. See `min_screen_inches` for when this is a server-side filter vs a name-based fallback.
min_screen_inchesNoMinimum screen diagonal in inches, for display products (monitors, TVs, laptops). With `category_id` (and a category that has a diagonal slider) this is Alza's own server-side diagonal filter (live-verified 2026-10-06), snapped to the slider's real sizes and reported in `appliedRanges`; like `filters`, that switches to the category-browse page, so `query` is not applied. Without `category_id` it falls back to parsing the product name's leading size (e.g. '40" MSI MAG401QR' → 40), excluding products whose name doesn't start with a size.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
queryYes
totalYes
pageSizeYes
productsYes
appliedRangesNo
candidatesScannedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly/openWorld/idempotent), yet the description goes well beyond them: Alza ignores server-side sort so price/rating sorts scan ~72 candidates client-side, unhonoured filters error rather than silently returning unfiltered results, `in_stock` is derived from the card CTA (excluding 'Hlídat'), and `min_screen_inches` is a server-side slider only with `category_id`, otherwise a name heuristic. These are exactly the non-obvious behaviors an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, return shape, and the `get_product` handoff are front-loaded before the dense caveat block, so the critical routing information comes first. It is long and repeats several parameter-level details already present in the schema (sort client-side behavior, screen-inch fallback), which costs some efficiency but not clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, quirk-heavy tool with an output schema, the description covers everything an agent must know to call it correctly: required `query`, when filters override it, what `candidatesScanned`/`appliedRanges` mean, and which filters are real versus name-based heuristics. Return values are only summarized, appropriately, since the output schema carries them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot: filters/screen-size switching to Alza's own category page and thereby nullifying `query`, and the interaction between `sort`, `candidatesScanned`, and `max_price` for a price floor. Some text (sort, screen inches) duplicates the schema descriptions, which caps it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Search the Alza.cz catalog by keyword') and immediately scopes intent to product discovery. It explicitly routes to the sibling `get_product` for single-item detail, so an agent can separate it from `compare_products`, `get_deals`, and `list_categories` without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('finding what's available, comparing options, or starting research'), a named follow-up path (`get_product`), and prerequisites for the filtered mode (`list_category_filters` first, then `producer_ids`/`filters` with `category_id`). It even states a when-not condition: `query` is ignored once a filter switches to the category-browse page.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools