Skip to main content
Glama

MAQAMI Travel

post_vouchers

Overview

Create discount vouchers that customers can apply to their hotel and flight bookings. Supports percentage discounts, fixed amounts, and points redemption vouchers.

When to Use

  • Promotional campaigns - Create discount codes for marketing

  • Customer rewards - Generate vouchers for loyal customers

  • Special offers - Create time-limited discount vouchers

  • Points redemption - Generate vouchers from loyalty points

What You Get

  • Voucher object - Complete voucher details including code and settings

  • Usage tracking - Remaining uses count

  • Validation - Confirmation that the voucher was created successfully

Key Features

  • Multiple discount types - Percentage, fixed amount, or points redemption

  • Flexible rules - Set minimum spend, maximum discount, and usage limits

  • Validity control - Define start and end dates

  • Guest assignment - Optionally assign to specific guests

  • Applies to hotels and flights - Pass the voucherCode in the voucherCode field of /rates/prebook (hotels) or /flights/prebooks (flights) to redeem the discount at checkout

Quick Start

Provide voucher code, discount type, value, currency, validity dates, usage limits, and status. Returns the created voucher with all details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
budgetNoTotal monetary pool the voucher can distribute across all redemptions, in the voucher's currency. If not set or 0, there is no monetary limit and usage is only controlled by usages_limit. When set, budget and usages_limit act as independent limits — whichever is exhausted first will reject the voucher.
statusYesCurrent status of the voucher (e.g., active, inactive)
currencyYesCurrency in which the discount is offered
guest_idNoThe unique identifier of the guest associated with the voucher
descriptionNoA brief description of the voucher, detailing its purpose or offer
usages_limitYesMaximum number of times the voucher can be redeemed
validity_endYesDate until which the voucher remains valid
voucher_codeYesA unique code for the new voucher. e.g. manhattan-holidays-100
discount_typeYesType of discount, such as percentage, or points_redemption
minimum_spendYesMinimum rate to apply the discount voucher in the voucher currency. e.g. a minimum_spend of USD$100 will only apply for bookings with a price USD$100 or more
discount_valueYesValue of the discount applied by the voucher. For percentage discounts, a value of 10 represents a 10% discount. For points_redemption, it indicates the fixed amount of points to be redeemed e.g. 10 equals 10 points
validity_startYesDate from which the voucher becomes valid
terms_and_conditionsNoTerms and conditions associated with the voucher
maximum_discount_amountYesMaximum discount amount that can be applied using the voucher in voucher currency. e.g. a with a maximum_discount_amount of 50 in USD, will discount from 0 to USD$50

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already disclose that this is a non-read-only, non-idempotent write operation, so the bar is lower. The description adds useful behavioral context by explaining what is returned (voucher object, usage tracking, validation confirmation) and how the voucher is redeemed in hotel and flight flows, though it does not discuss duplicate-call risk or permissions.

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

Conciseness4/5

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

The description is well-structured with front-loaded headings and an Overview that appears first. It is somewhat long and has some redundancy across 'What You Get' and 'Key Features,' but the length is defensible for a 14-parameter creation tool.

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?

Given the complexity of 14 parameters, 10 required fields, and no output schema, the description covers purpose, usage scenarios, return behavior, and redemption mechanics. It does not cover authentication, error cases, or non-idempotent duplicate-call risk, but it is largely complete for correct invocation.

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 all 14 parameters thoroughly, including nuanced fields like budget, minimum_spend, and discount_value. The description mostly repeats required inputs in the Quick Start and does not add significant syntax or constraint detail beyond what the schema provides.

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 discount vouchers that customers can apply to their hotel and flight bookings.' It also names the supported discount types, which makes the tool easily distinguishable from retrieval, update, and delete voucher siblings such as get_vouchers, put_vouchers_id, and delete_Voucher.

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 'When to Use' section gives clear contextual scenarios (promotional campaigns, customer rewards, special offers, points redemption), which helps an agent recognize appropriate calls. It does not state when not to use the tool or explicitly name alternative siblings, so it falls short of a 5.

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.

Resources