Retrieve Everlane storefront metadata as clean JSON, with the URL fixed server-side so no URL parameter is required.
Get Everlane store metadata. Returns storefront metadata for Everlane (https://www.everlane.com). The storefront URL is fixed server-side, so no url parameter is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.16.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully discloses that the storefront URL is fixed server-side and that no url parameter is accepted, but it never states that the operation is a read-only fetch, nor does it characterize the shape or breadth of the returned 'storefront metadata' (no output schema exists to cover this).
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?
Three short sentences, front-loaded with the action and resource, followed by the return scope and the parameter constraint. No filler or redundancy.
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 no-parameter, no-annotation, no-output-schema tool this is close to sufficient: the agent knows what it fetches and that no arguments are needed. A brief note on what fields the 'storefront metadata' contains would fully close the gap left by the absent output schema.
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 takes zero parameters, so the baseline is 4. The description goes slightly beyond that by pre-empting the natural assumption that a url parameter would exist, explaining why it does not. Useful, though not transformative for an empty schema.
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 Everlane store metadata') and names the exact storefront it targets, so the agent knows precisely what is returned. It does not, however, distinguish this storefront-metadata tool from its close siblings everlane_page, everlane_pages, or everlane_collections, leaving that separation to inference.
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?
There is no explicit when-to-use or when-not-to-use statement and no named alternative among the many everlane_* siblings. Usage is only implied by the fact that this is a metadata entry point, and the note about the fixed URL is a parameter constraint rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.