Skip to main content
Glama

Get current offers

get_current_offers
Read-onlyIdempotent

Returns the current merchant offers of one product (product_id, product slug or edition_id; region JP by default): price in integer minor units with currency_exponent plus price_display (the same amount formatted, e.g. ¥29,700, or 無料 for a price of zero), tax and shipping status, seller class, presentation_state (active, ending_soon, stale, scheduled, unverified), price_certainty, checked_at, fresh_until and expires_at. Prices are observations with a verification state, not guarantees. An offer past fresh_until has presentation_state stale: its price is the last checked price (see checked_at) and it is not a basis for a lowest price, budget fit, cheapest cost or list_deals prices_from; expired offers are not returned. An offer priced in another currency may carry converted (a yen estimate: amount_minor, display such as 約¥7,800, rate_source ecb_eurofxref, rate_reference_date, rate_basis direct or cross_via_eur, and basis_note, a fixed English sentence saying that this site computed the estimate from the European Central Bank's reference rates of that date and that it is not a price) that is not used for ordering, budget fit, cheapest cost or lowest_observed. field_availability.offers is not_recorded when no offer of the product has been recorded. customer_segment is general, or existing_owner, education or nfr for a row the store names as an upgrade, crossgrade, update, EDU or NFR edition (maker and distributor names are not read). Rows that are not general stay in this list with their segment and are not used for a product's default price, lowest price, list_deals prices_from or largest_discount_percent; lowest_observed has no element for editions named upgrade, crossgrade, update, EDU or NFR. A price or listing that a source keeps off this channel is marked withheld_by_channel_policy (offers_coverage=partial) and is not estimated; Rakuten Ichiba listings, for example, appear only on the web page. Each offer's permitted_handoff_links contains canonical_page and site_entry_page, and merchant_plain only where the source permits link distribution on this channel. An optional lowest_observed[] gives, per edition with price history, the window minimum (window_min_amount_minor, window_min_observed_at, observed_since, missing_days, merchant_count, basis_ja) and names the current offer when it is the lowest price seen so far (current_is_lowest_so_far, label_tier high / probable, label_ja, rule_id). current_is_lowest_so_far is true, false or null; null comes with lowest_so_far_undetermined_reason (no_current_price, current_offer_not_on_this_channel, no_price_drop_observed or not_comparable), and false means the current price is above the window minimum. window_min_display is the window minimum formatted. The window minimum is the lowest of our own observations and recorded external references, stated with its basis; it is not a vendor list price or a regular price. An offer of a subscription or rent-to-own edition carries billing_period (month or year): its price is the charge for one period, and it has no reference_price or discount_rate_bps; field_availability.billing_period is unknown when the period is not verified. Such editions have no lowest_observed element. A bundle product with a complete member list carries bundle_cards[]: per shop and currency, the bundle price, each included single product with its verified price at the same shop (amount_minor null with excluded_reason when there is none; never estimated), break_even_count (bundle price divided by the median single price, two decimals, rounded half up), discount_vs_singles_bps (the bundle price against the sum of the priced single prices in basis points, floored; negative when the bundle costs more than the singles; computed over members_priced of members_total), the formula with its inputs, snapshot_id and computed_at. An optional price_record[] gives, per edition and currency, the lowest price observed in the stated window and the last observed price drop at a shop, with the days since each; it records observations and is not a forecast. An optional record_badges[] gives, per edition and currency, record_low (the current price is the lowest of our own record since record_since, after a higher price was recorded; record_low_ja states it with its scope, and it is not the word 過去最安) with new_low_on, and the previous sale (the most recently ended sale that covered the edition at a store: its days, store and recorded price) with below_previous_sale (the current price is below every price recorded in that sale's days; below_previous_sale_ja). false means the badge is not stated. canonical_page is the product page on this site; it carries the complete price table (including listings withheld on this channel), the merchant purchase links and the affiliate disclosure. site_entry_page is the same page with the entry marker for this channel. Read-only; no purchase execution. Links are user_navigation handoffs (handoff_mode=user_navigation) and are not intended for prefetching or automatic clicking.

Input Schema

NameRequiredDescriptionDefault
regionNoJP
conditionNo
product_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / product_id / maxLength
      Previous value: -64New value: +160
  2. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, the description extensively discloses behavioral semantics: prices are observations with verification states, stale and expired offer behavior, withheld-by-channel-policy listings, segment restrictions, subscription billing handling, bundle calculations, and link handoff behavior. This is unusually rich context for an agent deciding whether and how to rely on the returned offers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, but it becomes a very long, dense paragraph that mixes input guidance, output field semantics, and business rules. Much of the detail may be necessary without an output schema, but the lack of structure makes it harder to scan than it should be.

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

Completeness5/5

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

Given the absence of an output schema and the complexity of the returned offer data, the description is highly complete. It explains the meaning of key return fields, edge cases, availability flags, lowest-observed behavior, bundle cards, price records, and record badges.

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 description coverage is 0%, and the description adds meaning for product_id by saying it may be a product slug or edition_id, and repeats the JP default for region. However, the condition parameter is never explained, and its enum values are left to the schema alone.

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?

The description states a specific verb and resource: it returns current merchant offers for one product, with product_id, slug, or edition_id and a default JP region. It is clearly about one product's offer data rather than searching or comparing products, though it does not explicitly name sibling tools such as search_products or compare_products.

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?

It gives useful usage context, including that stale offers must not be used for lowest price, budget fit, cheapest cost, or list_deals prices_from, and that the tool is read-only with no purchase execution. However, it does not explicitly say when to choose this tool versus search_products, compare_products, or resolve_purchase_request, leaving alternative selection mostly implied.

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