therealreal_collections

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that 'responses are cached' and that it is 'Credential-free public data sourced from The RealReal's own published sitemap,' covering caching behavior and authentication needs. It does not mention rate limits or error conditions, but for a simple reference tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences but the second sentence repeats the verb 'Returns' after the first sentence's 'Get,' creating slight redundancy. However, it is front-loaded with the main purpose and then provides necessary details about output and behavioral notes, making it efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool with no annotations, the description covers the purpose, how the output is used (as slugs for the collection endpoint), caching behavior, and authentication requirements. It does not specify the exact return format (e.g., array of strings), but the examples and explanation are sufficient for an agent to call it correctly.

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

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

The tool has zero parameters and schema coverage is trivially 100%, so the baseline for this dimension is 4. The description does not need to add parameter meaning, and it appropriately focuses on the output and usage instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get The RealReal curated collection slugs'), and distinguishes this tool from its sibling therealreal_collection by explaining that these slugs are 'usable directly against the collection endpoint's own slug field.' This makes the tool's role clear and prevents confusion with the singular collection tool.

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

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

The description implicitly instructs the agent to use this tool to obtain slugs for the collection endpoint, saying they are 'each usable directly against the collection endpoint's own slug field.' It does not explicitly name an alternative tool or state when not to use it, but the purpose is evident and sufficiently contextual.

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