Skip to main content
Glama
sepehr071

technolife-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Find cheapest products

tl_find_cheapest
Read-onlyIdempotent

Find in-stock products for a search and return a flat list sorted by real price after discount. Use filters for budget, brand, and category to locate low-cost matches.

Instructions

Find the cheapest in-stock products for a search, one flat list sorted by the real price after discount.

Use for the lowest price. Accessories and other models often match a model name: check the returned categories and brands, call again with category_code and brand_codes, and check titles. Prices are the site's featured offer, not always the cheapest seller: confirm with tl_product, which lists every seller and installment price.

Input Schema

NameRequiredDescriptionDefault
limitNoMax products to return.
pagesNoPages of 100 results to scan.
queryYesProduct name, Persian or English, e.g. 'آیفون 16'.
max_priceNoHighest price in Toman, e.g. 150000000.
min_priceNoLowest price in Toman, e.g. 50000000.
brand_codesNoBrand codes from `brands` of a result or tl_find_brand, e.g. [16, 19].
category_codeNoCategory code from `categories` of tl_search / tl_find_cheapest, e.g. 1 (phones), to skip accessories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv0.3.0
    • changedInput schema / properties / brand_codes / description
      Previous value: -"Brand filter codes from the `brands` list of a result or tl_find_brand, e.g. [16] (Lenovo) or [16, 19] (Lenovo or ASUS)."New value: +"Brand codes from `brands` of a result or tl_find_brand, e.g. [16, 19]."
    • removedInput schema / properties / brand_codes / title
      Removed value: -"Brand Codes"
    • changedInput schema / properties / category_code / description
      Previous value: -"Category filter code from the `categories` list of a tl_search / tl_find_cheapest result, e.g. 1 (mobile phones), to skip accessories."New value: +"Category code from `categories` of tl_search / tl_find_cheapest, e.g. 1 (phones), to skip accessories."
    • removedInput schema / properties / category_code / title
      Removed value: -"Category Code"
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / max_price / title
      Removed value: -"Max Price"
    • removedInput schema / properties / min_price / title
      Removed value: -"Min Price"
    • changedInput schema / properties / pages / description
      Previous value: -"Pages of 100 cheapest-indexed results to scan."New value: +"Pages of 100 results to scan."
    • removedInput schema / properties / pages / title
      Removed value: -"Pages"
    • changedInput schema / properties / query / description
      Previous value: -"Product name or words, Persian or English, e.g. 'آیفون 16' or 'لپ تاپ لنوو'."New value: +"Product name, Persian or English, e.g. 'آیفون 16'."
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • removedInput schema / title
      Removed value: -"tl_find_cheapestArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "tl_find_cheapestDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower, and the description adds genuinely useful traits: results are flat and sorted by post-discount real price, and the quoted price is the site's featured offer rather than necessarily the cheapest seller. It stops short of stating pagination/scan cost behavior despite the `pages` scan parameter.

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 is front-loaded in the first sentence and each following sentence carries a distinct instruction (refinement loop, price caveat). Slightly dense mid-paragraph phrasing ('Accessories and other models often match a model name') costs a little readability but nothing is filler.

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

Completeness4/5

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

With no output schema, the description does the work of describing the return by naming result fields (`categories`, `brands`, titles) and the ordering of the list. It is largely self-sufficient for a 7-parameter search tool, though it leaves the `pages`/`limit` scan-cost tradeoff and pagination behavior unexplained.

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 baseline is 3, but the description goes further by explaining the sourcing of category_code and brand_codes (they come from the result's `categories`/`brands` or from tl_find_brand) and the purpose of filtering by category (to skip accessories). That is usage meaning the schema text alone does not supply.

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 and resource ('Find the cheapest in-stock products for a search') plus the output shape ('one flat list sorted by the real price after discount'). It distinguishes itself from siblings by naming tl_product as the deeper seller-level tool, so an agent can separate it from tl_search and tl_compare without reading schemas.

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 an explicit selection rule ('Use for the lowest price'), an alternative for a different need (tl_product for every seller and installment price), and a concrete refinement loop: check the returned categories/brands, then re-call with category_code and brand_codes. Both when-to-use and when-to-look-elsewhere are covered.

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