Skip to main content
Glama
voucherifyio

voucherify-core-mcp

Official
by voucherifyio

qualifications

Find redeemables applicable to a customer, including vouchers, promotions, and campaigns. Uses customer profile and scenario to target marketing and optimize cart.

Instructions

Find redeemables (vouchers, promotions, campaigns) applicable to given customer.

āš ļø CRITICAL: The 'customer' parameter is ALWAYS REQUIRED - never call this tool without it!

Returns list of available discounts, vouchers, and promotions based on customer profile and selected scenario for targeted marketing and cart optimization.

Parameters:

  • customer: šŸ”“ MANDATORY - Customer identification and profile data. This parameter is REQUIRED for every call.

  • scenario: šŸ”“ MANDATORY - Qualification scope determining which redeemables to evaluate (optional, defaults to ALL)

Customer Object Structure: Required (one of):

  • id: Customer ID with 'cust_' prefix (e.g., "cust_abc123")

  • source_id: External customer identifier Optional:

  • metadata: Dict of custom customer attributes for rule matching

Scenario Guide (Choose Based on Use Case):

CUSTOMER-FOCUSED:

  • ALL: Scenario that returns redeemables available for the customer

  • CUSTOMER_WALLET: returns vouchers applicable to the customer's cart based on the vouchers assigned to the customer's profile

  • AUDIENCE_ONLY: returns all vouchers, promotion tiers, and campaigns available to the customer. It validates the rules based on the customer profile only.

PRODUCT-FOCUSED (require product context in other tools):

  • PRODUCTS: returns all promotions available for the products (when a discount is defined to be applied to the item or when the item is required in the validation rule)

  • PRODUCTS_DISCOUNT: returns all promotions available for products when a discount is defined as applicable to specific item(s).

  • PRODUCTS_BY_CUSTOMER: returns all promotions available for a customer for the products (when a discount is defined to be applied to the item or when the item is required in the validation rule).

  • PRODUCTS_DISCOUNT_BY_CUSTOMER: returns all promotions available for a customer for products when a discount is defined as applicable to specific item(s).

ADVANCED:

  • PROMOTION_STACKS: returns the applicable promotion stacks

Common Usage Patterns:

  • Customer wallet check: Use CUSTOMER_WALLET

  • Matching redeemables to given context: Use ALL

  • Customer-based targeting: Use AUDIENCE_ONLY

āœ… CORRECT Examples (always include customer):

  • qualifications(customer={"id": "cust_abc123"}, scenario="CUSTOMER_WALLET")

  • qualifications(customer={"source_id": "user_456", "metadata": {"tier": "gold"}})

  • qualifications(customer={"id": "cust_xyz789"}, scenario="ALL")

  • qualifications(customer={"id": "cust_abc123"}) # scenario defaults to ALL

🚫 WRONG Examples (missing required customer parameter):

  • qualifications() # āŒ NEVER do this - customer is required

  • qualifications(scenario="CUSTOMER_WALLET") # āŒ NEVER do this - customer is required

  • qualifications(scenario="ALL") # āŒ NEVER do this - customer is required

šŸ’” Remember: ALWAYS provide the customer parameter - it's never optional!

Returns: JSON object containing:

  • redeemables: Array of applicable vouchers/promotions

  • Each redeemable includes: id, name, discount details, validation rules

  • Scenario-specific filtering applied

Raises:

  • ToolError: If customer missing required fields or invalid scenario

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
customerYes
scenarioNoALL

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

The description covers return format, error handling (ToolError), and critical warnings about required parameter. It does not explicitly state read-only nature or auth requirements, but provides good transparency overall.

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?

The description is quite verbose with multiple sections and emojis. While well-structured, it could be more concise without losing value.

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?

Given the tool's complexity (2 parameters, nested objects), the description is complete: it covers all scenarios, provides correct/wrong examples, and explains return values and errors. Output schema exists but description still adds value.

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

Parameters5/5

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

Given low schema description coverage, the description adds significant meaning: it details the customer object structure (required fields, optional metadata) and explains each scenario value with its purpose, vastly exceeding the schema's minimal type definitions.

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 clearly states the tool finds redeemables applicable to a given customer, which is specific and distinguishes it from sibling tools like get_voucher or get_campaign.

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?

The description provides extensive guidance on when to use each scenario (CUSTOMER_FOCUSED, PRODUCT_FOCUSED, ADVANCED) with common usage patterns. It also emphasizes that customer is always required. However, it does not explicitly exclude cases where sibling tools might be more appropriate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/voucherifyio/core-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server