Skip to main content
Glama
Apple Store MCP
by washedguy

search_products

Search Apple Store pages and products by keyword, model, or part number, then discover sitemap pages or priced accessories with storefront, brand, and price filters.

Instructions

Find sitemap pages by default; use apple_search for Apple search tabs and priced accessories. Sitemap results are not a complete product catalog and do not have variant prices. Apple search filters apply locally to one page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_products"
  }
}

Input Schema

NameRequiredDescriptionDefault
tabNoSearch tab. 'accessories' returns buyable products with prices; 'explore' returns curated and content results.explore
pageNoResults page, starting at 1. Use next_page to continue.
brandNoFilter by brand (applied locally).
freshNoBypass the process cache and request current shop data.
queryYesProduct keywords, model number, or part number. Local-language terms may work best.
sourceNoSitemap page discovery or Apple search results. Sitemap does not contain individual product prices or variants.sitemap
countryNoStorefront country code, e.g. us, de, fr, ch, be. Use list_storefronts for supported values.us
languageNoShop language; defaults to the country's main language. Switzerland: de/fr; Belgium: fr/nl; Canada: en/fr.
max_priceNoMaximum price in the local currency (applied locally).
min_priceNoMinimum price in the local currency (applied locally).

Output Schema

NameRequiredDescriptionDefault
tabNo
noteNo
pageYes
cacheNo
countYes
queryYes
pagingYes
sourceYes
countryNous
coverageYes
languageNoen
productsYes
retailerYes
next_pageYes
observed_atNo
local_filtersNo
related_pagesNo
redirected_urlNo
total_productsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It usefully says sitemap results are not a complete catalog and lack variant prices, and that Apple search filters apply locally to one page. It does not discuss read-only/safety behavior, authentication, rate limits, or cache behavior, so transparency is only partial.

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?

The description is three sentences and front-loads the default and alternative source behavior. Some phrasing, especially 'Apple search filters apply locally to one page,' is slightly opaque, but there is no significant padding.

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 10-parameter tool with full schema descriptions and an output schema, the description needn't explain parameter formats or return values. It covers source selection and key data limitations, though it omits sibling-tool guidance and some operational behavior.

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 100%, so the baseline is 3. The description reinforces source limitations and local filtering but adds little parameter meaning beyond what the input schema already documents for source, tab, filters, and pagination.

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 default source ('sitemap pages') and an alternative mode ('apple_search') for Apple search tabs and priced accessories, so an agent can infer the tool searches product/sitemap sources. However, it frames the action as finding sitemap pages rather than product search and never explicitly distinguishes this tool from siblings such as browse_sitemap or get_product.

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 explicit guidance for the source parameter: default to sitemap, switch to apple_search for Apple search tabs and priced accessories. It does not say when to use this tool rather than sibling tools like get_product or explore_product, nor when browsing the sitemap directly is preferable.

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