tap
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TAP_STATE | No | Path to the state file where your cards, used credits and balances are stored. Defaults to ~/.tap/state.json. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| optimize_purchaseA | The step before you pay: call BEFORE paying for anything. Given the merchant, category and amount, ranks the user's cards by rewards earned (rates from CardSavvy's catalog) plus any statement credit that applies and hasn't been used this period, returns the conditions to check first (enrollment, activation, booking channel), the risks of the payment method, and credits and balances expiring within 14 days. Recommend the best card, relay the warnings, and ask the user the questions in ask_user (one at a time), saving answers with the set_/mark_ tools. |
| whats_expiringA | What the user is about to lose: balances (airline codes, earned credits, certificates) nearing expiry, and this period's card credits not yet used, soonest first, with what each needs (enrollment, booking channel, spend). Call it when planning trips or purchases, or when asked what's expiring. |
| list_cardsA | Lists the cards Tap knows (slug, name, annual fee) and which ones the user holds. Use it to match what the user says to slugs. |
| set_my_cardsA | Save which cards the user holds (replaces the list), and optionally each card's renewal date. Call it when the user tells you their cards. Only cards from list_cards are supported. |
| mark_creditA | Record what the user said about one card credit this period: used = true if they've used it, false if they confirmed it's still unused (Tap then stops asking until the period resets). Credit ids come from optimize_purchase and ask_user. |
| set_balanceA | Save a balance the user owns that can expire: an airline voucher or code, an earned credit, a certificate, points. Same name + program replaces; value 0 removes it. Never store account or member numbers. |
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 6 tools
Most tools have clearly distinct purposes, but whats_expiring and optimize_purchase both surface expiring credits/balances (optimize_purchase includes items expiring within 14 days). Descriptions help, but an agent asking about expiry could reasonably choose either tool.
Five of six tools follow a verb_noun pattern (set_my_cards, mark_credit, set_balance, optimize_purchase, list_cards). whats_expiring breaks the pattern as an interrogative phrase, and set_my_cards adds a possessive 'my' unlike the others, but the set remains readable.
Six tools cleanly cover the domain's core actions: list/set cards, set balances, mark credits, check expiry, and optimize purchases. There is no obvious bloat or thinness for the stated purpose.
Core write paths and purchase optimization are covered, but there is no tool to list all owned balances/credits (only expiring ones) and no explicit read of credit usage status. The referenced ask_user tool is also absent from the set, leaving a notable interaction gap.