Skip to main content
Glama
sepehr071

asalbanoo-mcp

by sepehr071

Filters of a category or brand

ab_filters
Read-onlyIdempotent

List attribute filters and in-stock product counts for a category or brand, then pass chosen values as filters to find sizes or types.

Instructions

List the attribute filters of a category or brand listing (volume, hair type, skin type, gender, origin...) with each value's product count.

Use before ab_browse when the user wants a size or a type inside a category: pass {attribute: [value, ...]} as ab_browse's filters. Counts cover in-stock items.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brandNoBrand slug from ab_brands, e.g. 'graph' or 'la-roche-posay'.
categoryNoCategory slug from ab_categories, e.g. 'hair-shampoo' or 'sunscreen'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real behavioral context beyond them: counts cover in-stock items only, and the output is intended as input to ab_browse filters.

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

Conciseness5/5

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

Three tight sentences: purpose first, then usage routing, then a scoping note on counts. No filler, front-loaded.

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

Completeness5/5

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

Output schema exists so return values need no explanation, annotations cover safety, params are fully documented, and the description supplies the only missing piece: when and how to use this tool relative to ab_browse.

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

Parameters4/5

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

Schema coverage is 100% and both params (brand, category slugs) are well documented, so baseline is 3. The description adds meaning by explaining the relationship between the returned attribute map and ab_browse's filters argument, which the schema does not convey.

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

Purpose5/5

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

States a specific verb+resource: lists attribute filters of a category or brand listing, with concrete examples (volume, hair type, skin type) and notes each value carries a product count. It is clearly distinct from siblings like ab_browse and ab_categories.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use before ab_browse when the user wants a size or type inside a category, and it even shows how to feed the result ({attribute: [value, ...]}) into ab_browse's filters. This is the when-to-use plus the inter-tool handoff.

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