What can you do with this server?

KiasuMiles is a Singapore credit card miles optimization server that helps you identify which credit card earns the most miles for any given merchant, based on your personal card stack. * List supported cards (kiasumiles_list_cards): Browse all supported Singapore credit cards, optionally filtered by bank. * Configure your wallet (kiasumiles_configure): Save or replace your personal card stack locally on your device — the hosted service never stores this data. * View your wallet (kiasumiles_get_wallet): Display the card names currently saved in your local wallet. * Look up best card for a merchant (kiasumiles_lookup): Get a ranked recommendation for the best card to use at a specific merchant, with optional outlet, payment channel (e.g. contactless, online), or spending category parameters. * Review weak categories (kiasumiles_recommend_stack): Analyze your saved card stack to identify spending categories that are under-covered. * Check data version (kiasumiles_data_version): Retrieve the current version of hosted card rules and merchant mappings. * Get agent guidance (kiasumiles_agent_guide): Retrieve workflow guidance and best practices for integrating KiasuMiles into an AI agent.

Which integrations are available for this server?

Supports Grab merchant lookups, providing the best credit card recommendation for earning miles when paying via the Grab app or at Grab merchants. Allows card recommendations for HSBC credit cards, enabling users to maximize miles at various merchants based on HSBC card earn rates and caps. Supports Shell fuel stations, providing the best credit card recommendation for earning miles at Shell locations. Supports Singapore Airlines online bookings, providing the best credit card recommendation for earning miles on flight purchases.

How do I use KiasuMiles?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KiasuMiles What card should I use at Cold Storage?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

KiasuMiles

by hosanxiv

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

KiasuMiles

“Which card do I use again?”

KiasuMiles helps you choose from the Singapore miles cards you already hold. Tell a compatible AI agent which cards are in your stack, ask about a merchant, and KiasuMiles ranks those cards using its centrally maintained card and merchant database.

The hosted KiasuMiles service does not store your card stack. It never needs your card number, expiry date, CVV, banking login or payment details.

Quick start

Send this message to your AI agent:

Connect me to KiasuMiles at https://kiasumiles.space/mcp if its tools are not already available.

Ask before changing settings or running installation commands. Do not say KiasuMiles is connected until you can list its tools and successfully call its data-version tool.

If you cannot add the connection yourself, say so plainly and give me only the documented setup steps for the AI agent I am using. Do not guess. Then wait for me to complete them.

Once KiasuMiles is available, check whether this installation provides tools to read or configure a saved card stack. If it does, show me any saved cards and ask whether I want to keep or change them. If it does not, explain how this AI agent can supply my selected cards for KiasuMiles lookups and whether my selections will persist between conversations.

Ask which banks I have cards with, show me the matching supported cards, and ask me to confirm my selections.

Use only the storage method documented by the available tools. Never claim the hosted KiasuMiles server stores my card stack.

After confirming my cards, ask for a Singapore merchant and recommend my best card.

This message is both a setup request and a capability check. Some AI agents can add the connection after asking for approval. Others require you or a workspace administrator to add it in settings.

Related MCP server: OpenRouter Model Selector MCP

Choose your AI agent

OpenClaw or Hermes through Telegram

Paste the quick-start message into your Telegram chat.

If your agent is allowed to update its MCP configuration, it can ask for approval, add KiasuMiles and verify the tools. This depends on the permissions configured by the person who runs your agent, so do not treat a success message as proof unless the agent can actually use the KiasuMiles tools.

Codex on desktop

In the desktop app:

Open Settings → MCP servers.
Select Add server.
Name it KiasuMiles.
Choose Streamable HTTP.
Enter:
```
https://kiasumiles.space/mcp
```
Save the server and restart the app.
Use /mcp to confirm that the KiasuMiles tools are available.
Send the quick-start message above.

Codex CLI users can add the same hosted server with:

codex mcp add kiasumiles --url https://kiasumiles.space/mcp

Then run codex mcp list or use /mcp to verify it.

Claude

Add KiasuMiles as a custom connector using Claude on the web or Claude Desktop:

Open Customize → Connectors.
Select + → Add custom connector.
Enter KiasuMiles and:
```
https://kiasumiles.space/mcp
```
Add the connector.
Enable it for the conversation, then send the quick-start message.

Claude currently makes custom connectors available on Free, Pro, Max, Team and Enterprise plans; Free accounts are limited to one custom connector. On Team and Enterprise plans, an Owner or Primary Owner must add the connector for the organisation before members can connect it.

Claude supports connectors on iOS and Android. Installing connectors on mobile is currently in beta, so web or desktop remains the more reliable setup path.

See Claude’s custom connector guide.

ChatGPT web and ChatGPT Work

Do not expect the quick-start message to install KiasuMiles by itself.

If your account or workspace provides custom MCP apps in developer mode, add KiasuMiles as a custom app on ChatGPT web using:

https://kiasumiles.space/mcp

Managed workspaces may require an administrator or owner to enable developer mode, create and review the app, and publish it to the workspace before members can use it.

After the app is available in a chat, send the quick-start message.

Custom MCP apps are currently web-only in ChatGPT. Do not claim that this setup works in the ChatGPT mobile app.

See OpenAI’s developer-mode and MCP app guide.

Another AI agent

Check whether it supports remote MCP servers over Streamable HTTP and lets you add a custom server URL. If it does, add:

https://kiasumiles.space/mcp

Then verify that it can list and call the KiasuMiles tools before relying on it.

First use

After KiasuMiles is connected:

Your agent asks which banks you use.
KiasuMiles shows the supported cards from those banks.
You confirm the cards you hold.
Your agent explains whether it can remember that selection.
You provide a merchant and, where useful, how you are paying.
KiasuMiles ranks only the cards supplied for that lookup.

Try:

What card should I use at NTUC FairPrice?

Your card stack and privacy

The hosted KiasuMiles MCP server has no wallet-save or wallet-read tools. For each hosted recommendation, the AI agent or client supplies the selected cards in that request.

Whether your card stack survives a new conversation depends on the AI agent or client you are using. KiasuMiles cannot guarantee that persistence, so ask the agent to explain its documented storage behaviour.

KiasuMiles needs only the names of your cards. Do not provide:

Card numbers
Expiry dates
CVVs
Banking usernames or passwords
One-time passwords
Transaction or account credentials

If your agent supports remembering your selection, you can ask:

Show me the card stack you use for KiasuMiles lookups.

Add OCBC 90°N to the card stack you use for KiasuMiles.

Remove UOB Preferred Visa from the card stack you use for KiasuMiles.

The agent should tell you whether that change will persist. These are requests to your agent; the hosted KiasuMiles server itself does not save the stack.

Troubleshooting

The agent says it cannot connect

Confirm that the agent supports remote MCP servers over Streamable HTTP.
Check that the endpoint is exactly https://kiasumiles.space/mcp.
Check whether your account or workspace allows custom connections.
Use the product-specific steps above instead of asking the agent to guess.

The agent says KiasuMiles is connected, but cannot list its tools

The connection has not been verified. Restart or reload the agent using its documented method, then require it to list the KiasuMiles tools and call kiasumiles_data_version.

My card stack disappeared in a new conversation

The agent or client did not persist it. Run the quick-start message again and ask the agent to explain its storage behaviour. The hosted KiasuMiles server is not a wallet store.

The recommendation is too broad

Include the exact merchant and payment method:

Which of my cards should I use at NTUC FairPrice with Apple Pay?

The service returns a rate-limit error

The hosted MCP endpoint defaults to 30 requests per 60 seconds for each IP address handled by a running service instance. If you receive HTTP 429, wait and retry.

Supported cards and data

Ask your agent:

Show me all cards currently supported by KiasuMiles.

The production service reports its current number of card rules, merchant records, data version and backend at:

https://kiasumiles.space/health

Records may include a confidence level and last-verified date, but those fields do not guarantee that every merchant classification or bank rule is current.

Recommendations are informational. Check the relevant bank’s current terms before making a large or unusual purchase.

For supported Amaze pairings, include both Amaze and the paired card in your selected stack so KiasuMiles can apply its configured adjustment.

Hosted MCP reference

KiasuMiles currently exposes five hosted MCP tools:

Tool	Purpose
`kiasumiles_list_cards`	Lists supported cards, optionally filtered by bank
`kiasumiles_lookup`	Ranks supplied cards for a merchant
`kiasumiles_recommend_stack`	Reviews category coverage among supplied cards
`kiasumiles_data_version`	Returns the data version, record counts and backend
`kiasumiles_agent_guide`	Returns integration and display guidance

Hosted lookups are stateless. The cards parameter is required, and the server does not retain it as a wallet.

Test the MCP connection

curl -i -X POST https://kiasumiles.space/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl-smoke","version":"1.0"}}}'

Public REST adapter

The hosted service also exposes a stateless REST adapter:

Route	Purpose
`GET /api/chatgpt/openapi.json`	OpenAPI schema
`GET /api/chatgpt/cards?bank=UOB`	Lists supported card names by bank
`POST /api/chatgpt/lookup`	Looks up a merchant using card names supplied in the request
`POST /api/chatgpt/recommend-stack`	Reviews the supplied card stack

The public adapter accepts card names and removes internal card IDs, merchant-category codes and internal reason codes from its JSON responses.

Example:

{
  "merchant": "NTUC FairPrice",
  "cards": [
    "UOB Preferred Visa",
    "Citi Rewards Mastercard"
  ],
  "channel": "mobile_contactless"
}

For maintainers

Production can load card rules and merchant mappings from Supabase. The repository includes a smaller bundled dataset for development and tests.

Environment variables:

KIASUMILES_SUPABASE_URL
KIASUMILES_SUPABASE_SERVICE_ROLE_KEY
KIASUMILES_SUPABASE_CARDS_TABLE — optional; defaults to card_rules
KIASUMILES_SUPABASE_MERCHANTS_TABLE — optional; defaults to merchant_mcc
KIASUMILES_DATA_BACKEND — optional; auto or supabase
KIASUMILES_RATE_LIMIT_REQUESTS — optional; defaults to 30; 0 disables the MCP rate limit
KIASUMILES_RATE_LIMIT_WINDOW_SECONDS — optional; defaults to 60

Backend selection:

auto: use Supabase when its credentials are present; otherwise use the bundled dataset
supabase: require Supabase and fail if it is unavailable

The database schema is at supabase/schema.sql. Both /health and kiasumiles_data_version report the selected backend.

Supabase keep-awake

The Supabase keep-awake GitHub Actions workflow performs one direct, read-only card_rules query at 08:17, 16:17, and 00:17 Singapore time each day. It does not use the hosted /health route, because a warm hosted process can serve cached data without touching Supabase. The query selects one identifier and never inserts, updates, or deletes data.

Configure the encrypted repository secrets:

In the GitHub repository, open Settings → Secrets and variables → Actions.
Choose New repository secret and create KIASUMILES_SUPABASE_URL with the production project API URL.
Choose New repository secret again and create KIASUMILES_SUPABASE_SERVICE_ROLE_KEY with the production service-role key used by the hosted backend.

Never put either value in the workflow file, source code, logs, or a pull request. The script prints only a generic success message or a sanitized error; a failed query exits non-zero so the workflow is visibly red in GitHub Actions.

The scheduled trigger starts only after the workflow is on the repository's default branch. After merging, open Actions → Supabase keep-awake → Run workflow once and confirm the run succeeds. Keep GitHub Actions failure notifications enabled so a failed scheduled run is noticed.

Feedback

If a recommendation appears wrong or a merchant is missing, message @kiasumilesbot on Telegram with the merchant name and the recommendation you received.

Changelog

See CHANGELOG.md.

About

KiasuMiles is built by Hosan, founder of The AI Burrow, Singapore’s applied AI collective for teams and builders who want to move past the hype and actually deploy.

MIT License

Available Tools

7 tools

kiasumiles_agent_guideC

Return guidance for the persistent local KiasuMiles workflow.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'Return guidance', implying a read-only operation, but does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or whether the guidance is static or dynamic. This is insufficient.

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 a single short sentence with no unnecessary words. However, it could be more structured to include key points like output format or usage context without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description is minimal. It does not explain what the guidance contains or how to interpret it. With no annotations and a vague purpose, the description is not complete enough for an agent to confidently invoke the tool in the right context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100%. With no parameters, the description cannot add meaning beyond the schema. Baseline is 4, and the description is acceptable for a no-parameter tool, though it adds nothing about the output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Return guidance for the persistent local KiaasuMiles workflow.' It identifies a verb ('Return') and a resource ('guidance for the persistent local KiaasuMiles workflow'), but 'guidance' is vague and does not specify what kind of guidance or its scope. It does not clearly distinguish from sibling tools like 'kiasumiles_configure' or 'kiasumiles_lookup'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Given siblings like 'kiasumiles_configure' and 'kiasumiles_recommend_stack', the description should explain what situation calls for returning guidance, but it provides no context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_configureB

Save or replace the user's KiasuMiles wallet on this device.

Use this after matching the card names the user carries. Include Amaze when mentioned. Confirm the saved card names in plain English. The hosted service does not store this wallet.

ParametersJSON Schema

Name	Required	Description	Default
`cards`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the action saves/replaces the wallet on the device and that the hosted service does not store it. However, it does not describe potential side effects (e.g., overwriting existing data), required permissions, or whether the action is reversible. The behavioral disclosure is adequate but not exhaustive.

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 four sentences, each serving a purpose: main action, usage timing, specific inclusion, and data locality. It is front-loaded with the primary function and avoids unnecessary words. It is concise and structured well.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no annotations) and the existence of an output schema, the description covers the main workflow: save/replace wallet, immediate usage context, and data storage note. It does not mention the output or confirmation, but the output schema presumably handles that. The description is mostly complete but could be slightly more specific about the expected outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds that card names should be included, specifically mentioning 'Include Amaze when mentioned,' but does not explain what each array item should be (e.g., exact card names, formatting). The parameter 'cards' is only implied to be a list of card names. This is minimal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Save or replace the user's KiasuMiles wallet on this device.' This is a specific verb-resource combination. It distinguishes from sibling tools like kiasumiles_get_wallet (read) and kiasumiles_list_cards (list). The additional context about not storing on the hosted service clarifies the scope.

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 description explicitly tells when to use the tool: 'Use this after matching the card names the user carries.' It also provides specific instructions: 'Include Amaze when mentioned. Confirm the saved card names in plain English.' This gives clear context for usage, though it does not explicitly state when not to use it or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_data_versionA

Return the current hosted card and merchant data version.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It accurately describes a read-only operation ('Return') with no side effects, which is transparent enough. However, it could mention that it is a safe, non-destructive call, but the lack of annotations does not lead to contradiction.

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

Conciseness5/5

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

A single, succinct sentence that conveys all necessary information without any superfluous words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description fully covers what the agent needs to know: the tool returns the current version of hosted card and merchant data. No additional context is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema coverage is 100%. The description adds meaning by specifying that the version pertains to 'hosted card and merchant data', which provides useful context beyond the empty schema. Baseline for 0 parameters is 4, and the description meets it.

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 uses a specific verb ('Return') and names the exact resource ('current hosted card and merchant data version'), making the purpose crystal clear. It also naturally distinguishes from sibling tools like 'kiasumiles_list_cards' or 'kiasumiles_lookup'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing the data version, but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use scenarios. Given the tool's simplicity, this is acceptable but not exemplary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_get_walletA

Show the card names saved in the local KiasuMiles wallet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates a read operation but does not disclose authentication needs, behavior if wallet is empty, or potential side effects.

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

Conciseness5/5

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

Single sentence, front-loaded, every word adds value. No extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, output schema exists), the description is complete enough. It tells the agent exactly what the tool does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, schema coverage is 100% and the description adds no param info. Baseline 4 is appropriate.

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 clearly states the verb 'Show' and the specific resource 'card names saved in the local KiasuMiles wallet'. It distinguishes from sibling tools like list_cards (which likely lists available cards) and recommend_stack.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. No mention of prerequisites or caveats.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_list_cardsA

List supported Singapore credit cards for local wallet setup.

Ask which banks the user has cards with first, then call this once per bank. Present card names only. Do not expose internal card IDs.

ParametersJSON Schema

Name	Required	Description	Default
`bank`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that listing can be filtered by bank, is idempotent/read-only, and specific output handling (card names, not IDs). More details on response format or pagination could improve it, but it's strong.

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

Conciseness5/5

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

Three sentences, no wasted words. Front-loaded with purpose, then usage instruction. Highly concise and well-structured.

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?

For a simple listing tool with one optional parameter and an output schema, the description covers essential use. Lacks mention of empty results or errors, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage for the 'bank' parameter. The description compensates by explaining that the tool should be called once per bank, implying the parameter filters results. It adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'List supported Singapore credit cards for local wallet setup.' The verb 'List' and resource 'cards' are specific. It does not explicitly differentiate from sibling tools, but the purpose is distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance provided: 'Ask which banks the user has cards with first, then call this once per bank.' Also instructs to 'Present card names only. Do not expose internal card IDs.' This is excellent usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_lookupA

Recommend the best saved card for a Singapore merchant.

The local wallet is attached automatically. Pass the exact merchant name plus outlet, channel, or category only when the user provides them. Never ask the user to repeat their saved cards.

ParametersJSON Schema

Name	Required	Description	Default
`outlet`	No
`channel`	No
`category`	No
`merchant`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses that 'The local wallet is attached automatically,' which tells the agent about internal state handling. However, it does not specify if the tool is read-only, what data it accesses, or any side effects. The instruction 'Never ask the user to repeat their saved cards' is agent-oriented, not tool behavior. More detail on security, rate limits, or error conditions would improve transparency.

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

Conciseness5/5

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

The description is four sentences with no redundancy. The first sentence establishes purpose, the second adds automatic wallet attachment, the third provides parameter usage, and the fourth gives a behavioral rule. Every sentence adds distinct value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters, no annotations, and an output schema (not shown). The description covers core usage and a behavioral rule but lacks details on error handling, recommendation criteria, or what happens when the merchant is unknown. Given the output schema likely documents return values, the description is adequate but not fully comprehensive. Omission of comparisons to siblings and missing descriptions of parameter meanings leave gaps.

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 0%, so the description must compensate for parameter meaning. It maps the required 'merchant' and optional 'outlet', 'channel', 'category' to user-provided information and instructs to pass them 'only when the user provides them.' However, it does not explain the semantics of each parameter (e.g., what constitutes an 'outlet' vs 'channel' vs 'category'), leaving the agent to infer meaning. This adds value beyond the schema but is insufficient for full understanding.

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 clearly states the tool's purpose: 'Recommend the best saved card for a Singapore merchant.' This provides a specific verb ('Recommend') and resource ('best saved card') with a geographic scope. It distinguishes the tool from siblings like 'kiasumiles_list_cards' (listing) and 'kiasumiles_recommend_stack' (possibly a different recommendation method).

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 description gives explicit usage instructions: 'Pass the exact merchant name plus outlet, channel, or category only when the user provides them.' This tells the agent how to invoke parameters. It also provides a behavioral rule: 'Never ask the user to repeat their saved cards.' However, it does not contrast with sibling tools (e.g., when to use 'kiasumiles_recommend_stack') or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kiasumiles_recommend_stackC

Review weak categories in the locally saved wallet.

ParametersJSON Schema

Name	Required	Description	Default
`top_n`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or output details. The output schema exists but is not described.

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 a single concise sentence, front-loaded with the main action. No redundant information, but it is too brief to be fully helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and an output schema, the description is incomplete. It does not explain what 'weak categories' are, how the review works, or how 'top_n' influences results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'top_n' parameter's meaning or effect. The default value is given in the schema but not elaborated in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Review weak categories in the locally saved wallet,' which indicates a verb and resource, but 'weak categories' is vague and the purpose is not clearly distinguished from sibling tools like 'list_cards' or 'get_wallet'. It lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives or what context is appropriate. There is no mention of prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.2Jul 14, 2026
- First observedkiasumiles_agent_guide
- First observedkiasumiles_configure
- First observedkiasumiles_data_version
- First observedkiasumiles_get_wallet
- First observedkiasumiles_list_cards
- First observedkiasumiles_lookup
- First observedkiasumiles_recommend_stack

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a distinct role: guidance, configuration, data version checking, wallet viewing, card listing, merchant lookup, and weak category review. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent 'kiasumiles_verb_noun' pattern (e.g., kiasumiles_configure, kiasumiles_list_cards). No mixing of conventions.

Tool Count5/5

With 7 tools, the server is well-scoped for a credit card wallet recommendation service. Each tool covers a necessary step in the workflow without redundancy.

Completeness4/5

The tool set covers setup, listing, lookup, recommendation, and versioning. Missing is a dedicated tool for updating or removing individual cards (only full replace via configure), but this is a minor gap.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

looptool
dev.looptool
An MCP server that automatically collects feedback on your MCP server.
Monitoring Developer Tools
2
mcpOAuth
com.stripe
MCP server integrating with Stripe - tools for customers, products, payments, and more.
App Automation E-commerce & Retail Finance
21,790
maxmind-minfraud A
io.usefulapi
MCP server for MaxMind minFraud — score transactions for fraud risk from your AI assistant.
Security Finance
42
MCP Finder B
io.github.c5huracan
Find the right MCP server for your task. 4,500+ servers ranked by community trust.
Search Developer Tools
3

Related MCP Servers

edhrec-mcp
Games & Gamification Search
getsec
F
license
A
quality
B
maintenance
MCP server for Magic: The Gathering Commander that provides card data from Scryfall and deckbuilding recommendations from EDHREC.
Updated 2 months ago (2026-06-27 03:11 UTC)
5
-
OpenRouter Model Selector MCP
AI & Machine Learning Search
rifatsaltoglu
A
license
Not graded
quality
C
maintenance
MCP server that helps AI assistants automatically find, filter, and rank the best AI models for a specific task using the OpenRouter API.
Updated 2 months ago (2026-07-14 11:44 UTC)
1
MIT
KoKo Finance MCP Serverofficial
Finance AI & Machine Learning
KokoFinance
A
license
Not graded
quality
B
maintenance
A hosted MCP server for AI-powered credit card advice, enabling search, comparison, portfolio analysis, and personalized recommendations for US credit cards through natural language.
Updated 3 days ago (2026-09-05 15:56 UTC)
1
MIT
Agentic Travel Recommendations
Beckett-Eiland
F
license
A
quality
C
maintenance
MCP server that provides AI agents with personalized travel recommendations for members, enforcing partner-specific rules such as category exclusions, loyalty tier eligibility, and recommendation caps.
Updated 2 months ago (2026-07-19 22:39 UTC)
3
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hosanxiv/kiasumiles'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

KiasuMiles

Quick start

Choose your AI agent

OpenClaw or Hermes through Telegram

Codex on desktop

Claude

ChatGPT web and ChatGPT Work

Another AI agent

First use

Your card stack and privacy

Troubleshooting

The agent says it cannot connect

The agent says KiasuMiles is connected, but cannot list its tools

My card stack disappeared in a new conversation

The recommendation is too broad

The service returns a rate-limit error

Supported cards and data

Hosted MCP reference

Test the MCP connection

Public REST adapter

For maintainers

Supabase keep-awake

Feedback

Changelog

About

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

KoKo Finance MCP Serverofficial

Latest Blog Posts

MCP directory API