colehaan_store

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 does well by disclosing that the data is 'credential-free', that the endpoint may fall back to a `*.myshopify.com` domain if `/products.json` is blocked, and that it may use embedded page data if neither source is available. This is meaningful behavioral context about failure modes and data sourcing. It doesn't describe return structure or rate limits, but for a simple zero-parameter metadata tool this is reasonably transparent.

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 three sentences with no wasted words. It front-loads the core purpose first, then adds the wrapper context and fallback behavior. Every sentence earns its place: purpose, parameter constraints, and failure-mode behavior are all covered in an efficient and logically ordered way.

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 brand-pinned metadata endpoint, the description covers the essential aspects: what data it returns (normalized storefront metadata), which brand and URL are pinned, and what fallback behavior exists. There is no output schema, so the agent must infer the return fields from 'storefront metadata', which is somewhat vague. But given the tool's simplicity and the strong fallback detail, this is sufficiently complete for an agent to invoke 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 input schema is empty with zero parameters, so the baseline is 4. The description goes beyond the baseline by explaining the absence of a url parameter: the storefront URL is fixed server-side. This directly addresses why the agent cannot pass a URL and preempts a common mistake for a Shopify-family wrapper. That semantic clarification is genuinely valuable.

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 opens with a specific verb and resource: 'Get Cole Haan store metadata.' It clearly states this returns normalized storefront metadata for a fixed brand URL, and explicitly distinguishes itself from the generic Shopify store family by explaining it is a 'brand-pinned wrapper' where the URL is fixed server-side. This differentiates it effectively from siblings like colehaan_products and generic shopify_store tools.

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 gives clear context on when to use this tool: it is specifically for Cole Haan store metadata, and it explains that no url parameter is accepted because the URL is fixed. This implies that for other stores or arbitrary Shopify URLs, one would use the generic Shopify store family. However, it does not explicitly state when NOT to use it (e.g., 'for products, use colehaan_products') or list alternative tools by name, so it falls just short of a 5.

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