KiasuMiles

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
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.
Average 3.6/5 across 7 of 7 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- Last stable release on July 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kiasumiles MCP server](https://glama.ai/mcp/servers/hosanxiv/kiasumiles/badges/card.svg)](https://glama.ai/mcp/servers/hosanxiv/kiasumiles)

Score Badge

Copy to your README.md:

[![kiasumiles MCP server](https://glama.ai/mcp/servers/hosanxiv/kiasumiles/badges/score.svg)](https://glama.ai/mcp/servers/hosanxiv/kiasumiles)

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