Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

chewy_item_attributes

Fetch Chewy product attributes and handling flags for up to 20 part numbers in one call, covering shipping rules, autoship, and bundle structure.

Instructions

Look up a batch of Chewy products' structured attributes and handling flags. Returns Chewy's own specification table for up to 20 products in one call, keyed by part number -- the structured attribute list (lifestage, pet type, product type, material, made-in country, packaging type, flavor, defining size, plus long-form key-benefits and cautions copy), together with the handling and compliance flags that govern how an item ships (pharmaceutical, prescription vet-diet, frozen, refrigerated, single-tablet, gift card), its bundle structure and component SKUs, its autoship eligibility/discount and preset reorder cadence, its merchandising classification path, and the numeric category group ids it belongs to (each usable directly as chewy_category's group_id). This complements rather than repeats chewy_products and chewy_product: price, rating, images, reviews, and descriptions stay on those endpoints, and the attribute table is not available from either. Use the group parameter to return a single attribute group. Part numbers Chewy does not recognize are reported in not_found; if none of them resolve the response is a 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoReturn only attributes in one group. One of DEFINING, STANDARD, EXTENDED, HIDDEN. Omit for every group.
part_numbersYesComma-separated Chewy part numbers, up to 20 per request, e.g. \

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / group / enum
      Added value: +[
      +  "DEFINING",
      +  "STANDARD",
      +  "EXTENDED",
      +  "HIDDEN"
      +]
  2. Addedv1.16.2

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: batch limit of 20 (up to 20 products in one call), keyed by part number, error handling (unrecognized part numbers reported in not_found; 404 if none resolve), and the full set of data fields returned (lifestage, pet type, handling flags, autoship, etc.). This goes well beyond a minimal description and gives the agent a strong behavioral model.

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 long but densely packed; every sentence contributes essential information. It is front-loaded with the core purpose, then details the return content, sibling differentiation, group parameter usage, and error behavior. While verbose, the complexity of the tool warrants the length, and there is no redundant or filler text.

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 must explain expected return values, and it does so thoroughly: it enumerates all attribute types, handling flags, bundle structure, autoship details, merchandising path, and category group IDs, plus the not_found and 404 behavior. It also clarifies the group parameter and batch size. For a tool with this complexity, the description is remarkably complete.

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%, with both parameters (part_numbers and group) already documented in detail, including the enum values for group and the comma-separated, up-to-20 constraint for part_numbers. The description adds only minor clarification on group usage and lists returned attributes, which are more about output than parameters. Since the schema already carries the semantic load, a baseline of 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 opens with a clear verb+resource: 'Look up a batch of Chewy products' structured attributes and handling flags.' It enumerates exactly what is returned (attribute list, handling flags, bundle structure, autoship, category IDs) and explicitly contrasts with sibling tools chewy_products and chewy_product, stating what those provide instead. An agent can immediately distinguish this tool from its siblings without inspecting schemas.

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

Usage Guidelines5/5

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

The description explicitly says what this tool is for versus alternatives: 'This complements rather than repeats chewy_products and chewy_product: price, rating, images, reviews, and descriptions stay on those endpoints, and the attribute table is not available from either.' It also instructs on the group parameter ('Use the group parameter to return a single attribute group'), giving clear selection guidance.

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