Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

oldnavy_product_availability

Check per-size, in-store pickup stock for an Old Navy, Gap, Banana Republic, or Athleta product at nearby or specified stores, returning in-stock, low-stock, or out-of-stock status.

Instructions

Check in-store pickup stock for an Old Navy, Gap, Banana Republic, or Athleta product. Checks per-size, in-store pickup stock status for one color (pid) at one or more physical stores. pid matches oldnavy-product's own color-level id. Give store location either directly with store_id (one or more comma-separated store ids, e.g. from a prior call to this endpoint or a value you already have) or with zip or both lat and lng, which resolves the nearest stores automatically. Select the storefront with the brand parameter (on for Old Navy, gap for Gap, br for Banana Republic, at for Athleta; defaults to on). Each returned store lists every offered size's stock status: in_stock, out_of_stock, or low_stock.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude to resolve the nearest stores from (must be given together with lng)
lngNoLongitude to resolve the nearest stores from (must be given together with lat)
pidYesColor-level Old Navy/Gap/Banana Republic/Athleta product id
zipNoZip code to resolve the nearest stores from
brandNoStorefront to check
store_idNoOne or more comma-separated numeric store ids

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / brand / enum
      Added value: +[
+  "on",
+  "gap",
+  "br",
+  "at"
+]
  2. Addedv1.14.0

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the burden. It discloses that results are per-size, scoped to one color, resolved to nearest stores automatically, and that each returned store lists `in_stock`, `out_of_stock`, or `low_stock`. This makes the read-only nature and response semantics clear (no destructive or write behavior implied).

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?

Five sentences pack the essential purpose, location-selection rules, brand mapping, and output semantics with no filler. The most important scope statement is front-loaded, and parentheticals carry examples rather than separate tangents.

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?

With no output schema, the description covers the key return behavior (each store lists per-size stock statuses) and all required input decisions (pid plus one of store_id/zip/lat+lng and optional brand). The tool is simple enough that this is sufficient for an agent to call it correctly; no critical details like pagination or auth are necessary for this read-only availability check.

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

Parameters5/5

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

Though the input schema already describes each field, the description adds crucial combinatory semantics: store_id is comma-separated and alternative to zip/lat+lng; lat and lng must be used together; brand maps to specific storefronts with a default. It also explains pid is the color-level id from oldnavy-product, tying it to a source. This goes well beyond the schema's individual field descriptions.

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?

Opens with a specific verb and resource: 'Check in-store pickup stock for an Old Navy, Gap, Banana Republic, or Athleta product.' It scopes the check to one color (pid) and one or more physical stores, and clarifies pid is the color-level id from oldnavy-product, which differentiates it from sibling tools like oldnavy_stores or oldnavy_product.

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

Usage Guidelines4/5

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

Describes the input selection logic: provide store_id directly, or zip/lat+lng for nearest-store resolution, and choose storefront via brand with explicit defaults. It does not explicitly name sibling tools or state when not to use it, but the pid-to-oldnavy-product link and the brand storefront selector give enough context for correct routing. A small gap is that alternatives like oldnavy_product are only implied, not stated.

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

Deploy Server

Other Tools