awardmath-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_programsA | List every rewards program AwardMath tracks. Returns {"names": {program_id: display name}, "plannable": [program_id]}. "plannable" ids are the ones a solve can spend today: award programs with priced charts, plus bank currencies that transfer into one. Use these ids in solve_award_trip wallets. |
| parse_walletA | Turn free text about points balances into structured wallet entries. Example input: "I have 250k Amex MR, 80k Chase, and my wife has 60k Alaska". Returns {"balances": [{owner, program, balance, expires}], "unrecognized": [...], "needs_clarification": [...]}. Anything ambiguous lands in the latter two lists instead of being guessed — show it to the user rather than dropping it. If you already know the balances in structured form, skip this and build the wallet directly. |
| solve_award_tripA | Compute up to three verified award-booking plans for a trip. wallet: [{"owner": "me", "program": "amex-mr", "balance": 250000}] — ids from list_programs; "expires" (ISO date) optional per entry. origins / destinations: IATA airport codes, e.g. ["LAX"] -> ["HNL"]. cabins: any of "economy", "premium", "business", "first" (default economy). max_cash_usd: cap on out-of-pocket cash (fees, points purchases). window_from / window_to: ISO dates, optional. Returns plans with exact transfer steps, points math, and fees, plus no_plan_reasons when nothing works — an empty result explains itself. Plans price the award from published charts; they never assert live seat availability, so tell the user to confirm space before transferring anything irreversible. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: list_programs enumerates available programs, parse_wallet converts free text into structured wallet entries, and solve_award_trip computes booking plans. There is zero overlap between them, so an agent can easily select the right tool for each step of the workflow.
All three tool names follow a consistent verb_noun pattern: list_programs, parse_wallet, solve_award_trip. The verbs are clear and the nouns match the domain, making the naming predictable and intuitive.
Three tools is well-scoped for the server's purpose: listing programs, parsing input, and solving trips. Each tool is necessary and sufficient for the end-to-end workflow, with no redundancy or missing helper clutter.
The tools cover the full lifecycle: discovering what programs exist, structuring user input, and computing booking plans with transfer steps. A minor gap is the lack of a dedicated tool for fetching detailed program rules or live availability, but the solve tool's output includes sufficient details and reasons for failures, so most practical needs are met.