Skip to main content
Glama
SZhukovWork
by SZhukovWork

search_products

Read-onlyIdempotent

Search Citilink's catalog with city, price, category, availability, and sorting filters to retrieve local prices, ratings, stock, and pickup information for comparison.

Instructions

Search Citilink like the site does: pages of 48, sorting, price window, category, availability.

Per item: regular price (null = not sold in the city), strikethrough price, club price only when the site shows it, bonuses (not a discount), lot size when sold in lots, the product's own rating next to the group rating the site shows, units in the area's stores, earliest pickup date, badges and promo codes, markdown flag. total_found is Citilink's match count; has_more whether another page exists; categories lists categories of the matches (use an id as category_id, a slug with find_markdown); price_range_rub is the site's price-filter span for the query (handy for cutting price windows).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity: id ('ekat_cl', 'ekat_cl:5x0029236') or name ('Екатеринбург', 'Кировск, Мурманская'). Default: CITILINK_CITY, else Екатеринбург
pageNoResult page, 48 items per page (Citilink's hard cap)
sortNoOrder: relevance, price_asc/price_desc, discount (biggest first), rating, opinions (most reviewed first)relevance
limitNoReturn at most this many items of the page
queryYesSearch phrase as typed on the site (Russian works best)
price_maxNoUpper price bound, rubles (regular price)
price_minNoLower price bound, rubles (regular price)
category_idNoNarrow to one category: an `id` from `categories` of a previous answer
availabilityNoany; in_store_now = the site's «Забрать через 5 минут» filter (quick pickup in the city's area); pickup = «Доступен самовывоз»; delivery = «Доступен для доставки»any

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent/openWorld annotations by disclosing detailed output semantics: null regular price means not sold in the city, bonuses are not discounts, club price appears only when the site shows it, and total_found/has_more/categories/price_range_rub are all explained. No behavior contradicts the annotations.

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

Conciseness5/5

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

The description is dense but well organized: one opening sentence covers query controls, followed by a structured block of per-item and response-level semantics. Every sentence adds necessary detail for a complex search tool, with no filler or repetition.

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 9-parameter search tool with a rich output, the description covers query controls, per-item fields, pagination signals, category mapping, and the price-filter span. Schema and annotations handle parameter formats and safety, and the description adds the behavioral and output nuance needed to call the tool correctly.

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?

The schema already documents all 9 parameters at 100% coverage, so the baseline is 3. The description adds meaningful cross-parameter guidance: it ties the categories output to category_id, advises using a slug with find_markdown, and frames price_range_rub as a helper for setting price windows.

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

Purpose4/5

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

The description opens with a specific verb and resource ('Search Citilink') and enumerates the key dimensions: pages of 48, sorting, price window, category, and availability. This clearly identifies it as a product-search tool, though it does not explicitly distinguish itself from sibling tools like get_product or get_reviews.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or exclusion of alternatives. The phrase 'Search Citilink like the site does' implies the primary use case, but with six siblings such as get_product, compare_products, and get_reviews, the description never tells the agent when to prefer this tool over those.

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