Natural-language fashion search and complete outfits from real shop pieces. Anonymous, read-only.
Scored across 2 tools
The two tools have clearly distinct purposes: one generates complete outfits, while the other searches for individual fashion products. Their descriptions explicitly warn against using them for the other's role, reducing misselection.
Both names use snake_case, but the pattern is mixed: `generate_outfit` is verb_noun while `semantic_search` is adjective_noun. The names remain readable, but they do not follow a single predictable convention.
Two tools are quite thin for a fashion stylist server, though they cover the core outfit-generation and product-search paths. The scope feels borderline rather than fully well-scoped.
The server covers outfit generation and product search, but there are notable gaps: no visualization tool despite the description mentioning visualization-only requests, and no product-detail or outfit-refinement operations. Agents can work around some gaps but may hit dead ends.
Use this when the user wants a complete outfit. Primary chat path is prompt-based generation; widget actions may call this with product_id for item-based outfit generation. Pass gender when you know who the outfit is for. Do not use this for single-item product search. The result's content is a plain-text summary of the outfit (each piece with brand and price); structuredContent.outfit holds the same pieces with product ids and shop links.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | ||
| gender | No | Who the clothes are for: 'female' or 'male'. Set it whenever the user says or the conversation suggests it ('for my boyfriend', 'women's', a gender they mentioned earlier, the kind of piece they ask for). Only ask the user if there is no hint at all and the answer would clearly differ by gender. Omit for unisex requests. | |
| prompt | No | ||
| max_budget | No | Total outfit budget in EUR. Pass the user's budget when they give one, and a high one (e.g. 3000) when they ask for designer or luxury pieces. Omitted, the outfit is kept to about EUR 700. | |
| product_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, non-destructive, open-world operation, so the safety profile is covered. The description adds genuinely useful return-shape context (plain-text `content` versus `structuredContent.outfit` with product ids and shop links) that no annotation provides. It says nothing about latency, sourcing or what happens when no outfit matches, so it is good rather than rich.
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?
Four sentences, no filler, with the trigger condition front-loaded before the alternatives and the return-shape note last. The prompt-versus-widget routing sentence is dense but carries real routing information, so nothing is wasted.
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?
With no output schema, the description correctly takes on the job of explaining content versus structuredContent.outfit, which is the most valuable thing it does. What is missing is only the meaning of the `init`-style optional `image` input, a modest omission for an otherwise complete definition.
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?
Schema coverage is only 40%, so the description must compensate, and it does for product_id (item-based generation) and prompt-based flows. The gender guidance and max_budget default are already fully documented in the schema, so they earn no extra credit. The `image` parameter, however, is left completely unexplained in both schema and description, which is a real gap.
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 resource (a complete outfit) and the triggering user intent ("when the user wants a complete outfit"), and it explicitly distinguishes itself from single-item product search, which maps to the sibling semantic_search. The verb 'generate' is only implied by the tool name, but the outcome is unambiguous.
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?
It gives explicit when-to-use (complete outfit requests), when-not ("Do not use this for single-item product search"), and the two invocation paths: prompt-based for chat and product_id for widget item-based generation. An agent can route between this and semantic_search without further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to find specific fashion products (clothing, footwear, accessories) by text, optionally guided by images. Pass gender when you know who the clothes are for. Do not use this for full outfit generation or visualization-only requests. The result's content is a plain-text list of the products (brand, price); structuredContent.products holds the same products with ids and shop links.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| gender | No | Who the clothes are for: 'female' or 'male'. Set it whenever the user says or the conversation suggests it ('for my boyfriend', 'women's', a gender they mentioned earlier, the kind of piece they ask for). Only ask the user if there is no hint at all and the answer would clearly differ by gender. Omit for unisex requests. | |
| images | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the safety profile is handled. The description adds real value beyond that by documenting the return shape: `content` is a plain-text list and `structuredContent.products` carries ids and shop links. It stops short of describing ranking, result caps, or how image inputs change the search, which would be the remaining behavioral gaps.
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?
Four short sentences, front-loaded with the trigger and the exclusion, then the gender hint and the return shape. Each sentence carries distinct information with no repetition of the name or annotations.
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?
No output schema exists, and the description usefully explains both return channels, which is exactly what an agent needs. The main incompleteness is the undocumented `images` parameter contract and absent notes on result limits or ranking, which matter for a search tool.
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?
Schema coverage is only 33%: `query` has no description and `images` has neither type detail nor guidance in the schema. The description adds a little on gender ('pass when you know who the clothes are for') and hints at the role of images ('optionally guided by images'), but never explains what `images` accepts (URLs, base64, IDs) or how the query interacts with them. It partially compensates but leaves a clear gap for a low-coverage 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?
States a specific verb and resource ('find specific fashion products (clothing, footwear, accessories) by text, optionally guided by images') and explicitly contrasts itself with the sibling: 'Do not use this for full outfit generation or visualization-only requests.' An agent can distinguish it from generate_outfit without opening either schema.
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?
Gives a clear trigger ('when the user wants to find specific fashion products by text'), an explicit exclusion (outfit generation, visualization-only), and guidance on the optional gender parameter ('Pass gender when you know who the clothes are for'). Routing decision is fully determined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_outfitsemantic_searchRead-only fashion and beauty product search across popular online shops, any price, any language.
Search and get fashion products recommendations across multiple e-ecom stores
Fashion & apparel MCP: visual outfit search, stock verification, and 1-click checkout.
Fashion & apparel MCP: visual outfit search, stock verification, and 1-click checkout.
Add one secure layer between your agents and this server.
