Skip to main content
Glama

Compare editions

compare_products
Read-onlyIdempotent

Computation only: per-edition differences (license, billing_period for a subscription or rent-to-own edition, formats, OS, capabilities, cheapest known cost over the offers this channel may disclose, budget fit) for 2 to 10 edition ids under the same channel policy as resolve_purchase_request. Each row has canonical_page and site_entry_page. 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. cheapest_cost is taken from the default confirmed-route class first, as in resolve_purchase_request; an edition with a cheaper confirmed listing outside that class is named in assumptions (key cheapest_cost_default_route_first, value the edition id, note_ja with the amount). An edition with no price in the requested currency keeps cheapest_cost in the original currency, with budget_fit unknown and the assumption key cheapest_cost_foreign_currency (value the edition id); cheapest_cost 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. Each row's price_checked_at is the check time of that price. Stale offers (past fresh_until) are not used for cheapest_cost. A general edition is priced from general rows only; a named restricted edition (upgrade, crossgrade, update, EDU or NFR) is priced from its own rows, with customer_segment on cheapest_cost, eligibility_status conditional and the assumption restricted_edition_price once per segment. A row whose edition the site has measured itself also carries measurements in full: environment (host machine, OS, DAW and version, audio interface, sample rate, buffer size, tools), product_version, settings, measured_at, comparison conditions, procedure, results ({ value, decimals } per named field), runs and result_statistic, failure cases, material rights and disclosure. They are not a sound-quality rating and not part of differing_fields; numbers compare only between editions listed in compared_edition_ids. Bounded compute class (shared with POST /api/v1/compare). Links are user_navigation handoffs (handoff_mode=user_navigation) and are not intended for prefetching or automatic clicking.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNosummary
localeNoja-JP
regionNoJP
constraintsNo
edition_idsYes
schema_versionYes
ownership_claimsNo
user_supplied_pricesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / edition_ids / items / maxLength
      Previous value: -128New value: +160
    • changedInput schema / properties / ownership_claims / items / properties / edition_id / maxLength
      Previous value: -128New value: +160
    • changedInput schema / properties / ownership_claims / items / properties / entitlement_id / maxLength
      Previous value: -128New value: +160
    • changedInput schema / properties / user_supplied_prices / items / properties / edition_id / maxLength
      Previous value: -128New value: +160
    • changedInput schema / properties / user_supplied_prices / items / properties / offer_id / maxLength
      Previous value: -128New value: +160
  2. First observed

TDQS

A3.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: stale-offer exclusion (past fresh_until), default-confirmed-route-first pricing, foreign-currency fallback with assumptions, restricted-edition pricing rules, bounded compute class, and that links are user_navigation handoffs not for prefetching. This is unusually rich disclosure of non-obvious semantics.

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

Conciseness2/5

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

The description is one massive run-on block of tightly packed clauses with no headings, bullets, or front-loading of the key usage decision. Nearly every clause carries real information, but the structure makes it hard to scan and the output-field detail crowds out the input guidance.

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 documents return fields (canonical_page, site_entry_page, cheapest_cost with its currency-conversion sub-fields, assumptions, per-edition measurements). It is strong on output semantics, though it remains thin on the input parameters an agent must supply.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters with nested objects, so the description carries the full burden, but it explains almost none of the inputs: detail (summary/full), locale, region, ownership_claims, and user_supplied_prices are never described. It hints at constraints concepts (budget fit, license, formats, OS) and echoes the 2-10 edition bound, but leaves the remaining parameters undocumented in both schema and description.

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?

Opens with a concrete verb and resource ('Computation only: per-edition differences ... for 2 to 10 edition ids') and enumerates the differing fields (license, billing_period, formats, OS, capabilities, cost). It distinguishes itself from siblings by tying its channel policy to resolve_purchase_request, though the dense jargon costs some immediate clarity.

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?

Usage is only implied: it assumes the caller already knows the channel policy 'as resolve_purchase_request' and never states when to pick this over get_current_offers, list_deals, or search_products. There is no explicit when/when-not framing, so the agent must infer the comparison use case from the purpose text.

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