Skip to main content
Glama

LebTech - electronics prices in Lebanon

Prices for one product

get_product_prices
Read-only

Live per-shop prices for ONE product in Lebanon: every shop that has the identical configuration in stock, cheapest first, with links to the shop's own product page. Takes a LebTech product id or a lebtechlb.com /product/ or /laptop/ URL.

Input Schema

NameRequiredDescriptionDefault
productYesA product id or a lebtechlb.com /product/ or /laptop/ URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral context: prices are live, results are restricted to shops holding the identical configuration rather than any similar model, and rows are sorted cheapest first with deep links. It doesn't address what happens when no shop stocks the item, but the added context is substantive.

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?

Two sentences, front-loaded with the resource and scope, then the input contract. Every clause carries information (scope, ordering, link inclusion, accepted input forms) with no 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?

For a one-parameter tool with no output schema, the description usefully sketches the return shape (per-shop rows, sorted, linked) and the matching constraint. It leaves the zero-results case and URL/id edge cases unstated, a minor gap given the low complexity.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter's description already enumerates the accepted id and /product/ or /laptop/ URL forms. The description restates exactly the same accepted formats, adding no syntax, validation, or example beyond the schema.

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 resource ('live per-shop prices') with an explicit scope ('for ONE product in Lebanon') and even the ordering ('cheapest first'). That scoping immediately separates it from category-level tools like cheapest_in_category and from search_products, without needing to name them.

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

Usage Guidelines3/5

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

The description implies when to use it (you have one product and want shop-by-shop prices) and tells you what input it accepts, but it never explicitly says when not to use it or which sibling to pick instead (e.g. search_products to obtain an id, price_history for trends). Usage is inferable rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources