MAQAMI Travel

post_vouchers

Create discount vouchers for hotel and flight bookings with percentage, fixed-amount, or points-redemption discounts, usage limits, and validity dates.

Instructions

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

Name	Required	Description
`budget`	No	Total 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.
`status`	Yes	Current status of the voucher (e.g., active, inactive)
`currency`	Yes	Currency in which the discount is offered
`guest_id`	No	The unique identifier of the guest associated with the voucher
`description`	No	A brief description of the voucher, detailing its purpose or offer
`usages_limit`	Yes	Maximum number of times the voucher can be redeemed
`validity_end`	Yes	Date until which the voucher remains valid
`voucher_code`	Yes	A unique code for the new voucher. e.g. manhattan-holidays-100
`discount_type`	Yes	Type of discount, such as percentage, or points_redemption
`minimum_spend`	Yes	Minimum 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_value`	Yes	Value 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_start`	Yes	Date from which the voucher becomes valid
`terms_and_conditions`	No	Terms and conditions associated with the voucher
`maximum_discount_amount`	Yes	Maximum 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.

First observedv0.1.0Sep 28, 2026

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.

Deploy Server