Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

petsmart_product

Retrieve a PetSmart product's full catalog details by SKU, including descriptions, attributes, variations, promotions, and shipping data; optionally use country=ca for Canadian products.

Instructions

Get one PetSmart product's full detail. Returns one product's full public detail by SKU: everything /petsmart/search returns plus the full description (as text and as PetSmart's HTML), short description, manufacturer name and SKU, every UPC, all category paths, the size and flavor variation options, current promotions, shipping dimensions and every other catalog attribute PetSmart publishes (life stage, food form, flavor, health considerations and so on) under attributes. An unknown SKU returns a 404. Pass country=ca for the Canadian catalog.

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": {
      "id": "<id>"
    },
    "name": "petsmart_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesProduct SKU, from /petsmart/search's id field.
countryNoOptional catalog: us (default) or ca for the Canadian store, which has its own products (about 9,000), categories, filters and prices.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does most of it well: it enumerates what is returned (descriptions, manufacturer, UPCs, category paths, variations, promotions, shipping dimensions, attributes), names the error behavior for unknown SKUs, and explains that the Canadian catalog is a separate product set. It does not mention pagination, rate limits, or auth, but for a public single-record lookup those are minor omissions.

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 first sentence front-loads the core purpose, followed by the return payload, the error case, and the country note in a sensible order. The long enumeration of returned fields is verbose but justified because there is no output schema. A few items ("and so on", "every other catalog attribute") are slightly loose but not wasteful.

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?

Because there is no output schema, the description must explain return values, and it does so exhaustively — describing both the inherited search fields and the extended detail fields including the nested attributes bag. Combined with the 404 behavior and the two-catalog distinction, an agent has everything needed to call it correctly.

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 coverage is 100%, so both parameters are already documented, including the country enum and its meaning. The description reinforces the SKU-based lookup and restates the country=ca behavior, which is useful framing but adds no syntax or semantics beyond what the schema already provides. Baseline 3 is appropriate.

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?

The description uses a specific verb and resource ("Get one PetSmart product's full detail" ... "by SKU") and distinguishes itself from the search endpoint by framing its output as "everything /petsmart/search returns plus" the extended fields. An agent can tell this is the single-product detail lookup rather than the list/search tool without opening either schema.

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?

Usage is clearly implied: fetch by SKU when full detail is needed, with the search endpoint referenced as the source of the SKU and as the thinner alternative. It also states the failure condition ("An unknown SKU returns a 404") and the catalog switch ("Pass country=ca for the Canadian catalog"). It stops short of an explicit "use petsmart_search instead when..." routing sentence, so it is not a full 5.

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