Skip to main content
Glama

WizStore — Israeli supermarket prices

מבצעים

find_deals
Read-onlyIdempotent

Today’s strongest supermarket deals: promotions that bring a common product at least 10% below its national median shelf price — nationally, or for one chain. Each deal has deal_price (per unit), the chain’s shelf price, the national median, club_only, the promotion text and its end date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoOptional chain, by name or slug, e.g. "שופרסל", "rami-levy"
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the 10%-below-median threshold, the national-or-single-chain mode, and club_only as a payload attribute — all relevant to interpreting results.

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?

One dense sentence that front-loads the deal definition before enumerating payload fields. No waste, though the field list at the end stacks several concepts and could be marginally tighter.

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 enumerates returned fields (deal_price per unit, shelf price, national median, club_only, promotion text, end date), which is exactly the burden a no-output-schema tool places on prose. Only the limit parameter's behavior is left unspecified.

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 only 50% (limit has no description). The description compensates by explaining that results can be national or restricted to one chain, which clarifies the optional chain parameter and the default mode when it is omitted. It does not explain limit's pagination/cap behavior.

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+resource ('Today's strongest supermarket deals') and nails down the inclusion criterion — promotions at least 10% below national median shelf price. This is far more precise than siblings like chain_price_index or cheapest_stores_in_city, and an agent can tell it apart without opening any schema.

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 scoping rule (national vs. one chain) implies when the tool applies, but there is no explicit guidance on when to choose it over compare_basket_by_chain or get_product_prices. Usage is inferable from the deal criterion 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