Singapore miles card optimizer with a local wallet and live hosted recommendations.
KiasuMiles demonstrates solid tool design with clear action verbs, comprehensive parameter schemas, and domain-specific descriptions. All 7 tools have explicit descriptions (avg 156 chars) and well-typed input schemas. However, output schemas are not documented in the source, parameter descriptions lack constraint details (ranges, enums, formats), and error handling guidance is absent. The hosted-only tools (lookup_hosted, compare_payment_methods) are well-scoped for agent composition. Tool naming follows verb_noun convention consistently. Missing: output schema documentation, enum constraints for categorical parameters (channel, category), and recovery guidance in error cases.
Return concise hosted integration guidance for agents. Use this for diagnostics, installation checks, or when an agent needs presentation rules.
Summarize source-neutral card and merchant rule changes since an ISO date.
Compare payment methods for the same merchant and supplied card stack. Use this when payment method is unspecified or the user asks whether to pay by mobile wallet, physical contactless card, online, or through Amaze.
Return the current KiasuMiles data version and row counts for diagnostics and freshness checks.
List supported Singapore credit cards and their stable card IDs for hosted MCP requests.
Primary hosted tool for Singapore card/merchant recommendations. Use this whenever the user asks which card to use, what to tap, or which card earns the most miles at a Singapore merchant.
Output schemas not documented. Tools return structured data but LLMs cannot plan downstream calls without knowing response field names and types.
Categorical parameters lack enum constraints. 'channel' accepts free-form strings (mobile_contactless, contactless, online) but no enum is declared; 'category' similarly undefined. LLMs will hallucinate invalid values.
Parameter descriptions lack constraint details. 'amount_sgd' has no min/max; 'limit' in changes_since has default=20 but no bounds stated; 'top_n' in recommend_stack has default=3 but no range. LLMs may pass absurd values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Analyze a stateless wallet card list for weak categories. Use this when the user asks whether their current card stack is good or what weak categories exist.
No error handling guidance. Tools return data or fail silently; no recovery hints (e.g., 'If merchant not found, try search_merchants()' or 'Invalid card ID, call list_cards() to see valid IDs'). Agents cannot self-correct.
Tool descriptions do not state when to use each tool vs. alternatives. lookup_hosted and compare_payment_methods both accept merchant + cards; unclear when to call which. Agents waste reasoning cycles.