makeup.land
Server Details
Israeli cosmetics retailer: ΔE shade matching, customer wallet, cart, orders, gift cards.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Each tool targets a distinct resource or action (cart, customer, deals, brands, orders, payment links, products, gift cards), with no overlapping functionality.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_cart, list_products, validate_gift_card), making the API predictable.
Eight tools cover a reasonable scope for a makeup loyalty server, focusing on queries for customer data, products, orders, and gift cards without being excessive or minimal.
The server lacks mutation tools (add to cart, create order, update customer) necessary for a full e-commerce workflow, leaving agents unable to perform essential actions beyond reading data.
Available Tools
8 toolsget_cartFetch a customer's cartAInspect
Return the customer's most-recently-updated cart with per-line and total reward projection. Bearer + phone required.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | E.164 phone selecting the customer whose cart to return. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states return value and auth requirements but does not explicitly confirm no side effects or rate limits. It is minimally adequate.
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 extremely concise: two sentences covering purpose and prerequisites. Every sentence contributes value.
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 simple single-parameter retrieval tool, the description covers the key aspects: what is returned and what is required. It lacks error conditions or edge cases, but given no output schema, it provides adequate context.
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 schema fully describes the phone parameter (pattern, required). The description only reiterates that phone is required, adding no additional semantic value. Baseline 3 for high coverage.
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 clearly states the tool returns the most-recently-updated cart with reward projection. It uses a specific verb and resource, and the tool's purpose is distinct from sibling tools like get_customer and list_orders.
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 provides necessary prerequisites (Bearer token and phone number) but does not specify when to use this tool versus alternatives like get_customer or list_orders. No guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_customerLookup customer by phoneAInspect
Return tags, ℳ-credit balance, M Club tier for the customer with the given E.164 phone. Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | E.164 phone number, e.g. +972501234567. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses auth requirement and output fields, implying a read operation. Could be more explicit about being non-destructive but is fairly transparent for a lookup.
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?
One sentence plus 'Bearer required.' is extremely concise. Every word is purposeful and front-loaded. No extraneous content.
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?
Simple tool with one parameter: description covers purpose, output fields, and auth. No output schema, but return values are explicitly listed. Missing sibling guidance, but adequate for the complexity.
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 100% (phone parameter documented with pattern). Tool description repeats 'E.164 phone' without adding new meaning beyond schema, meeting baseline.
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?
Description clearly states verb ('Return'), resource ('customer'), and specific fields ('tags, ℳ-credit balance, M Club tier'). It distinguishes from sibling tools like get_customer_best_deals by focusing on phone lookup with specific output.
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?
Description indicates 'Bearer required' (auth requirement) but lacks explicit when-to-use vs alternatives. Usage is implied by purpose, but no when-not or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_customer_best_dealsPersonalised best deals for a customerAInspect
Top deal projections based on the customer's tags + M Club tier. Bearer + phone required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max deals to return. | |
| phone | Yes | E.164 phone selecting the customer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses authentication (Bearer) and input requirements (phone), but does not detail behavioral traits like read-only nature, error handling, or rate limits.
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?
Single, well-structured sentence with 12 words, front-loaded with purpose, no 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?
Given no output schema, the description omits return format details. It is moderately complete for a simple tool, but lacks explicit info on what 'deal projections' looks like.
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 already covers both parameters with clear descriptions (limit integer, phone pattern). Description adds 'Bearer + phone required' but does not significantly enhance parameter meaning beyond 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 clearly states the tool retrieves 'top deal projections' based on customer tags and M Club tier, distinct from sibling tools that handle carts, customers, or general listings.
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 mentions authentication and phone requirement, providing clear usage context. It implicitly differentiates from siblings by focusing on personalized deals, but lacks explicit when-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brandsList all brandsAInspect
Return every brand with product counts and slugs. Bearer required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses authentication requirement ('Bearer required') and that it returns all brands, but lacks details on pagination, rate limits, or any side effects.
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?
Extremely concise: two short sentences with no unnecessary words, front-loading the main purpose.
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?
Given no parameters and no output schema, description provides essential info (returns brands with counts and slugs). However, missing mention of pagination or total results could be needed for complete understanding.
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?
No parameters exist (0 required), and schema description coverage is 100%, so description does not need additional parameter info. Baseline 4 is appropriate.
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?
Clearly states the tool returns every brand with product counts and slugs, which is specific and distinguishes it from sibling tools like get_cart or get_customer.
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?
No guidance on when to use this tool versus alternatives. Only mentions 'Bearer required' as a prerequisite, but no context on filtering or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ordersList a customer's ordersCInspect
Recent orders with 6-axis status (order / payment / fulfillment / delivery / return / review). Bearer + phone required.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number. | |
| limit | No | Page size. | |
| phone | Yes | E.164 phone selecting the customer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states 'recent orders' and lists status axes but does not clarify read-only nature, ordering, pagination behavior, or state changes. The description is vague about output structure, which is critical for a data retrieval tool.
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 very short (one sentence) and front-loaded with purpose. It conveys key points efficiently without redundancy, but the brevity compromises completeness in other dimensions.
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?
Given three parameters and no output schema, the description lacks essential context about return format, ordering (what defines 'recent'), and interpretation of status axes. It fails to compensate for missing annotations, leaving the agent underinformed.
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 100%, so baseline is 3. The description adds meaning by specifying that 'phone' selects the customer and implies authentication via 'Bearer + phone required'. However, no extra detail is given for 'page' or 'limit' beyond the 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 clearly states the tool lists 'recent orders' and provides domain-specific detail with '6-axis status', making the purpose specific. It distinguishes from sibling tools like get_cart or list_products, though not explicitly contrasting them in the description.
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 mentions authentication ('Bearer + phone required') but gives no guidance on when to use this tool versus alternatives like get_customer_best_deals or list_orders (though no direct sibling named list_orders). No when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_payment_linksList pending payment linksAInspect
Pending payment_requests on the customer's unpaid orders. Bearer + phone required.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | E.164 phone selecting the customer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists pending payment requests and requires authentication, but does not detail behavior such as read-only nature, rate limits, or effects on data. Adequate but not 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?
The description is extremely concise with two short sentences, front-loading the key information. No wasted words.
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 simple list tool with one parameter and no output schema, the description covers purpose and authentication. However, it does not mention the return format or whether results are paginated, which would be helpful for completeness.
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 100%, and the description does not add meaning beyond the schema's description of the phone parameter. The baseline of 3 is appropriate as the schema already defines the parameter well.
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 clearly states the verb 'list' and the resource 'pending payment links' on unpaid orders. It distinguishes from siblings like get_cart or list_orders by specifying the scope (pending requests on unpaid orders).
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 implies usage for retrieving pending payment links but does not explicitly state when to use it or provide alternatives. The mention of 'Bearer + phone required' indicates prerequisites but no exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsList / search productsAInspect
Browse the catalog with tag, brand, near_hex (ΔE shade match), hue_family, and sort filters. Bearer becomes required when passing phone (rewards projection).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Natural-language query. Cross-lingual semantic search — `lipstick`, `שפתון`, `lápiz labial` each return Hebrew-tagged lipsticks (the sets may differ across languages but are semantically equivalent). Prefer this over `tag` for any category lookup that isn't already in exact Hebrew. | |
| tag | No | Filter by an EXACT tag string. Tags are Hebrew (e.g. שפתון, ביוטי, עיניים, שפתיים). English category names rarely match — use `q` instead for natural-language queries. | |
| page | No | 1-indexed page number. | |
| sort | No | Sort order. Default: relevance. | |
| brand | No | Filter by brand slug or name. | |
| limit | No | Page size, default 20. | |
| phone | No | E.164 phone for per-customer rewards projection. REQUIRES bearer auth. Omit for anonymous catalog browse. | |
| near_hex | No | Target hex color for ΔE-ranked shade matching. Examples: '#C2185B', 'E8D4B8'. Each returned product carries a `shade_match: {hex, delta_e}` field with the closest variant swatch and its perceptual distance. | |
| hue_family | No | Post-filter on hue family. Must be paired with another filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It correctly notes that bearer auth is required when passing 'phone', but does not disclose other traits like read-only status, rate limits, or side effects. The behavioral caveat for phone is useful but not comprehensive.
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 two sentences, front-loading the action and key filters. Every word earns its place, with no redundancy or waste.
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?
Given 9 parameters and no output schema, the description is relatively short. It lacks overall behavioral context (e.g., pagination behavior beyond page/limit, response structure) and does not synthesize the many filtering options into a coherent example or use case.
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 description coverage is 100%, so the baseline is 3. The description adds context for near_hex (ΔE shade match) and hue_family, but these are already detailed in the schema. It does not significantly enhance understanding beyond what the parameter descriptions provide.
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 clearly states the tool's purpose: 'Browse the catalog with... filters', which is specific and distinguishes it from siblings like list_brands and other tools. The verb 'browse' and resource 'catalog' are explicit.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies its use for catalog browsing but does not mention when not to use it or provide contextual exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_gift_cardValidate a gift card codeAInspect
Check a gift card's remaining balance using its code. Public endpoint — no bearer required (gated on knowledge of the code).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Gift card code (full string as printed on the card). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that the endpoint is public and requires no authentication, which adds behavioral context. It does not describe errors or response format, but for a simple read operation, the transparency is adequate.
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?
Two sentences, no wasted words. The main purpose is front-loaded, and the behavioral information is appended concisely.
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?
Given one simple parameter and no output schema, the description is mostly complete. It states what the tool does and how to access it. It could briefly mention the return value, but inferring 'balance' from the description is straightforward.
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 100% for the single parameter 'code', and the description does not add additional meaning beyond the schema's description of the code format. Therefore, it meets the baseline without further enhancement.
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 clearly states 'Check a gift card's remaining balance using its code,' which specifies the verb and resource. It distinguishes itself from sibling tools like get_cart or list_products, which are unrelated.
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 provides context that it is a public endpoint requiring no bearer token but access is gated by knowledge of the code. It does not explicitly mention when to use alternatives, but the uniqueness of gift card validation makes this sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!