Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

therealreal_designers

Fetch The RealReal designer directory for a chosen department, returning each recognized designer's ID and slug for search or designer lookups. Cached reference data.

Instructions

Get The RealReal designer directory. Returns every designer The RealReal recognizes in one department (not just designers with currently active listings), each with an id (usable directly against search's designer_id) and slug (usable directly against the designer endpoint). The directory is segmented by department -- pass category to select one; the response's categories field lists every accepted value. This is reference data that changes rarely, so responses are cached.

Input Schema

NameRequiredDescriptionDefault
categoryNoDesigner-directory department. One of: women, men, fine-jewelry, watches, art, home, kids. Defaults to women

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

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 load and does disclose real behavioral traits: the directory is exhaustive (includes inactive designers), it is 'reference data that changes rarely,' and 'responses are cached.' That caching note is genuinely useful and not derivable from schema or annotations. It omits auth/permission and rate-limit details, but for a read-only reference endpoint this is solid.

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?

Four sentences, each carrying distinct information: purpose/scope, output fields and their downstream use, department segmentation, and caching. Purpose is front-loaded and nothing is redundant.

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?

For a single-optional-parameter tool with no annotations and no output schema, the description covers what is returned (id and slug), how to pick a department, how values are discovered, and the caching behavior. An agent has everything needed to call and chain this tool 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% and the schema already enumerates the accepted category values, so the schema does the heavy lifting. The description adds only the framing that category selects a department and that valid values live in the response's categories field, which is mild added meaning on top of a fully documented parameter.

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 The RealReal designer directory') and immediately scopes it ('every designer The RealReal recognizes in one department, not just designers with currently active listings'). It also clarifies the distinction from the singular designer endpoint by noting the slug is usable against it, giving the agent enough to tell this directory tool apart from sibling lookups.

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?

Explains how to select a department ('pass category to select one') and how to discover valid values (the response's categories field). It also signals downstream usage of the returned id/slug. It stops short of an explicit when-not-to-use statement, so it is clear context rather than full routing 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