Able.Style

Manage Wardrobe Item

add-to-or-remove-from-wardrobe-by-id

DestructiveIdempotent

Adds or removes a known clothing item from the user's personal wardrobe by its style ID. Use this tool when users want to track clothing items they own or indicate they have something similar. Use cases: "Add this to my wardrobe", "I have a similar jacket", "Mark that I own this", "Remove this from my wardrobe". Requires authentication - if user is not logged in, this will trigger an OAuth authentication flow. Wardrobe items are used to personalize outfit suggestions with clothes the user actually owns. IMPORTANT: Before calling this tool, look at the structured output of the most recent suggest-outfit-tool call earlier in this conversation. The styleId required by this tool is at outfitItems[i].styleIdentifier.styleId in that result — it IS present in your context. Do not claim you cannot see the styleId without first examining that tool result. If after examining it you still cannot find a matching item, tell the user and ask them to request a new outfit suggestion first.

Input Schema

Name	Required	Description
`styleId`	Yes	The unique identifier of the clothing style/item. IMPORTANT: This value MUST be copied exactly from the `styleIdentifier.styleId` field returned in the most recent previous `suggest-outfit-tool` response. You DO have access to previous tool responses. They are in JSON format. Review the tool call responses earlier in the conversation to find the correct styleId to use here and look for the most recent one from `suggest-outfit-tool`. Do NOT fabricate, guess, or invent this value. Once you think you have it, double-check the most recent suggest-outfit-tool response to confirm you are using the correct value from the context. If no valid styleId is available from a prior `suggest-outfit-tool` response, do not call this tool — instead tell the user that you need to suggest an outfit first before you can add an item to their wardrobe. If no item from the prior outfit suggestion seems to match what the user is describing, you can ask the user for more details about the item they want to add or remove, and then use that information to determine if any of the items from the prior outfit suggestion are a match. But you should never guess or make up a styleId.
`addOrRemove`	Yes	The action to perform: "add" to include the item in the user's wardrobe, or "remove" to delete it from their collection. Use "add" when user says "I have this shirt" or "Add the shoes to my wardrobe". Use "remove" when user says "I don't have the pants anymore" or "Remove the sneakers from my wardrobe".
`isUserStyle`	Yes	Whether this is a user-created custom style (true) or a catalog style from the platform (false). Most items from outfit suggestions will be catalog styles (false). IMPORTANT: This value MUST be copied exactly from the `styleIdentifier.isUserStyle` field returned in the most recent previous `suggest-outfit-tool` response. Do NOT guess this value.
`categoryName`	No	Provide the category name of the style to add to or remove from the wardrobe. For example: "Jackets", "Shirts", "Trousers", "Shoes". This value is provided in outfit suggestion responses in the "category" field.
`styleDescription`	Yes	The user-friendly description of the style to add to or remove from the wardrobe. IMPORTANT: This value MUST be copied from the `description` field of the outfit item returned in the most recent previous `suggest-outfit-tool` response.

Output Schema

Name	Required	Description	Default
`result`	Yes	The wardrobe update result.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is largely covered. The description adds genuinely new context: authentication is required and an OAuth flow will trigger if the user is logged out, plus the downstream effect that wardrobe items personalize outfit suggestions.

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

Conciseness3/5

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

Purpose and use cases are front-loaded, which is good, but the closing paragraph is bloated with repeated, near-identical warnings about not fabricating the styleId and re-examining context. The same admonition appears in both the description and the styleId schema field, so it does not earn its length.

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

Completeness4/5

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

An output schema exists so return values need no explanation, and the description covers the auth requirement, the required upstream suggest-outfit-tool call, and the fallback behavior. Complete for correct invocation, with only the sibling-disambiguation gap remaining.

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 description coverage is 100%, so the schema already documents every parameter, including the enum for addOrRemove and the sourcing of styleId/isUserStyle/styleDescription. The description repeats rather than extends that guidance, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb pair and resource ('Adds or removes a known clothing item from the user's personal wardrobe by its style ID'), which implicitly distinguishes it from the from_description and from_image siblings. However, it never explicitly differentiates itself from add-to-or-remove-from-closet-tool, which sounds near-identical in purpose.

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?

Gives concrete when-to-use triggers ('Add this to my wardrobe', 'I have a similar jacket'), the prerequisite that a prior suggest-outfit-tool call must exist, and an explicit when-not path ('If no valid styleId is available... do not call this tool'). It stops short of naming sibling alternatives such as add_wardrobe_item_from_image.

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

All Able.Style tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?