Skip to main content
Glama

La Luer — AI Skincare Commerce

create_checkout

Create a checkout URL for one or more products. Pass variant IDs (items) and/or product URLs (product_urls). When a product URL is provided (e.g. https://laluer.com/products/mira), the tool resolves it to a variant ID automatically — no catalog import needed. Supports discount codes, cart notes, and selling plans. Do not use unless the user wants to buy — use search_products or skincare_recommend first. Returns a direct Shopify checkout link the user can click to buy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoCart note visible to the merchant
itemsNoProducts to add to cart by variant ID
decision_idNoDecision Check ID from a prior /validate call. Required when this merchant enforces authority-gated checkout (decision_policy.authority_mode: "enforce", or the legacy require_authority_for_checkout alias); ignored otherwise.
product_urlsNoProducts to add to cart by URL — resolved to variant IDs automatically
discount_codeNoDiscount code to apply (e.g. 'WELCOME10')

TDQS

A4.9/5.0
Behavior5/5

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

The annotations are minimal (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description must carry the behavioral details. It does: automatic product-URL-to-variant resolution with no catalog import needed, support for discount codes and selling plans, and the return of a direct Shopify checkout link. These are meaningful operational traits.

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?

Two compact sentences, each earning its keep. The core operation is front-loaded, the coverage of discounts/notes/selling plans is brief, and the usage guardrail is appended efficiently with alternatives.

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?

For a commerce checkout tool with 100% schema coverage, the description covers the essential context: supported product input forms, what the tool returns (clickable checkout link), and preconditions for invocation. The unresolved authority-gated checkout nuance lives in the schema's decision_id description, which is acceptable.

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%, so the schema already documents all parameters. The description adds value by tying variant IDs to 'items', product URLs to 'product_urls', and by explaining that product URLs are resolved automatically. It does not merely repeat the schema.

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?

The description opens with a specific verb and resource: 'Create a checkout URL for one or more products.' This immediately distinguishes the tool from sibling tools like search_products or skincare_cart, and the two supported input modes (variant IDs and product URLs) are explicitly named.

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?

The description is explicit about when to use the tool: 'Do not use unless the user wants to buy — use search_products or skincare_recommend first.' This names the alternatives and the condition that should route the agent away from the tool, leaving no ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between skincare_cart and create_checkout, as both handle checkout creation, which could cause confusion. Additionally, search_products and skincare_recommend are well-differentiated by their descriptions, but an agent might misselect between them if the user's intent is ambiguous. Overall, the tools are mostly clear with minor areas of potential overlap.

Naming Consistency3/5

The naming follows a mixed pattern: some tools use verb_noun (e.g., check_compatibility, compare_products), while others use noun_verb (e.g., skincare_recommend, skincare_cart). This inconsistency, with variations like deals_discounts (plural nouns) and skincare_report_issue (noun_noun), reduces predictability. However, the names are still readable and descriptive, avoiding chaotic conventions.

Tool Count5/5

With 10 tools, the count is well-suited for an AI skincare commerce server, covering key e-commerce and recommendation functions without being overwhelming. Each tool serves a specific role in product discovery, inventory, comparison, checkout, and support, making the set appropriately scoped for the domain.

Completeness4/5

The toolset provides comprehensive coverage for skincare commerce, including product search, recommendations, inventory checks, compatibility analysis, and checkout processes. Minor gaps exist, such as the lack of tools for updating or managing user accounts or handling post-purchase support like returns, but core workflows are well-covered, allowing agents to function effectively.

Resources