Skip to main content
Glama
sepehr071

asalbanoo-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Find cheapest product

ab_find_cheapest
Read-onlyIdempotent

Find the lowest-priced in-stock products matching a keyword, sorted by price in Toman. Scan more results to uncover additional cheaper matches.

Instructions

Find the cheapest in-stock products for a keyword, one list sorted by price (Toman).

Use for the lowest price of X. Only titles containing every query word are kept by default (the site search also matches descriptions). Check ab_product for the size you need. complete=false means more in-stock matches lie past scanned: raise scan.

Input Schema

NameRequiredDescriptionDefault
scanNoHow many in-stock search results to scan, cheapest first.
limitNoMax offers to return.
queryYesProduct name or keyword, Persian or English, e.g. 'شامپو ضد شوره' or 'la roche posay'.
match_all_wordsNoKeep only titles that contain every word of the query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.0
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / match_all_words / title
      Removed value: -"Match All Words"
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • removedInput schema / properties / scan / title
      Removed value: -"Scan"
    • removedInput schema / title
      Removed value: -"ab_find_cheapestArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "ab_find_cheapestDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive. The description adds real behavioral context beyond them: default word-matching on titles only, that site search also matches descriptions, and crucially the meaning of complete=false and the need to raise 'scan' to reach more matches.

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?

Front-loads the core purpose, then usage and mechanics in short sentences. Slightly choppy line breaks and an unlabeled 'scanned' reference cost it a bit, but there is little wasted text.

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 usefully sketches the return shape (a price-sorted list) and the coverage signal (complete/scanned). It omits any mention of currency edge cases or empty-result behavior, but is otherwise sufficient for correct invocation.

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 goes further by explaining result ordering (price, in Toman) and the interplay between 'scanned' and complete=false, which the schema fields alone do not convey.

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?

States a specific verb and resource: 'Find the cheapest in-stock products for a keyword, one list sorted by price (Toman).' The scope (in-stock, price-sorted, single list) clearly separates it from a general search, but no sibling is named to make the distinction explicit.

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

Usage Guidelines4/5

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

Gives a clear use case ('Use for the lowest price of X') and routes to an alternative ('Check ab_product for the size you need'). It stops short of stating when NOT to use it or naming ab_search as the general-purpose counterpart.

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