market-screening
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MARKET_SCREENING_CONFIG | Yes | Path to the market-screening config.toml file containing your store codes. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_storesC | Stores configured by the user (chain, store code, name). Use the |
| search_productsA | Search a product in the configured stores. query: what to look for, in Russian, e.g. "молоко 2.5%", "куриное филе". stores: optional list of store keys from list_stores (default: all). Returns per store a list of products: price in rubles, old_price if on promo, unit_price per kg / l / pcs (compare by this), stock, badges, url. Search is fuzzy: results can include unrelated items (e.g. oat drink for "молоко"). |
| optimize_basketA | Compute the cheapest way to buy the basket. basket: [{"item": "молоко", "quantity": 2, "offers": {"magnit:123456": 89.99, "dixy:123": 92.5}}]
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool occupies a distinct stage of a clear pipeline: list_stores enumerates configured stores, search_products finds items with prices, optimize_basket computes the cheapest multi-store purchase. There is no overlap in purpose or output, so an agent cannot plausibly misselect.
All three names follow the same snake_case verb_noun convention (list_stores, search_products, optimize_basket), with the verb accurately signaling the operation (list vs. search vs. optimize).
Three tools map cleanly onto the domain's three steps (enumerate stores, search products, optimize basket), so no tool is filler. It sits at the lean end of appropriate: there is no direct product-lookup or price-refresh tool, which would round the set out.
The end-to-end flow (stores -> products -> cheapest basket) is covered and the schemas are explicit about how data passes between tools. The gap is that prices/offers must be hand-carried from search_products into optimize_basket, and there is no key-based product or price lookup to refresh an item without a new fuzzy search.