Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

goat_search_facets

Fetch valid filter values for GOAT search (categories, colors, brands, etc.) to ensure your query parameters are accepted.

Instructions

Get GOAT search facet values. Returns the accepted values for goat_search's filter parameters: categories, colors, genders, conditions, brands, and years are returned live so a value GOAT adds is discoverable without any client-side change, while product_types and activities are served from a maintained list because GOAT exposes no live facet for them. brands is GOAT's top brands ordered by product count, not the complete brand list -- when brands_truncated is true, brands beyond the ones listed exist and remain valid goat_search values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

A4.3/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 burden and does well: it discloses that categories/colors/genders/conditions/brands/years are served live while product_types/activities come from a maintained list, and it explains the brands_truncated semantics (top brands by product count, truncated list still fully valid). It omits auth/rate-limit context and any hint of the return shape, which for a zero-param tool is a minor gap.

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 purpose is front-loaded in the first sentence, and the dense detail about live vs maintained facets and brands truncation is genuinely informative rather than filler. It is a single long, information-dense paragraph rather than cleanly segmented, which slightly hurts scannability.

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 zero-param, no-annotation, no-output-schema tool, the description supplies what an agent needs: what is returned, why some facets are live and others static, and how to interpret a truncated brands list. It does not describe the response envelope, but with no output schema this is a modest remaining gap rather than a blocking one.

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

Parameters4/5

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

Zero parameters gives a baseline of 4. The description goes further by enumerating the facet dimensions returned (categories, colors, genders, conditions, brands, years, product_types, activities), which exceeds what an empty schema conveys, though it cannot add per-parameter meaning because none exist.

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?

States a specific verb and resource ('Get GOAT search facet values') and immediately frames the tool relative to its companion, goat_search, by naming the exact filter parameters whose accepted values it returns. An agent can distinguish it from goat_search and from other goat_* siblings without opening any 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?

The description makes clear this is the lookup used to resolve valid values for goat_search's filter parameters, which strongly implies the when-to-use context (before/alongside goat_search). It does not, however, name any alternative or state an explicit 'use this when you need to validate a filter value' condition, leaving the routing to inference.

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