ONE HEART eSIM
Server Details
一心eSIM商品目錄查詢與下單服務：查詢各國eSIM上網方案的即時價格與庫存、依旅遊天數與用量推薦方案、協助建立訂單並取得LinePay或ECPay付款連結。
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 5 of 5 tools scored.
Each tool has a distinct role: listing countries, searching/recommending plans, getting plan details, and creating orders. The descriptions clearly differentiate them, avoiding any overlap.
All tool names follow a consistent verb_noun pattern (e.g., list_esim_countries, get_esim_plan_detail) using snake_case, making them predictable and easy to understand.
With 5 tools, the set covers the essential operations for an eSIM ordering service—discovery, selection, and purchase—without being excessive or insufficient.
The tools cover the full purchase flow from listing countries to placing an order, but lack a way to retrieve or manage existing orders (e.g., order history or status), which is a minor gap.
Available Tools
5 toolscreate_esim_orderAInspect
建立一筆真實的一心eSIM訂單，並取得真實的付款連結（LinePay或ECPay綠界，二擇一）。 這是會實際寫入正式訂單、串真實金流的動作，不是模擬或試算。
呼叫前必須先完成：
已用search_esim_plans/recommend_esim_plan/get_esim_plan_detail取得正確的productId、 spec，不要自己編造或憑記憶帶入。
已把商品名稱、規格、數量、單價與總金額，跟使用者逐一覆誦確認過，並取得使用者明確 同意下單（不能因為使用者說「好」「幫我訂」等籠統回應就自行猜數量或規格）。
已取得使用者的email與稱呼/姓名（兩者都必填：email用於辨識訂單歸屬與寄送購買憑證/ eSIM QR碼；姓名是訂單聯絡資料的必要欄位，不能留空或代填）。手機可選填。
已詢問使用者想用LinePay還是ECPay綠界付款（留空預設LinePay，但有得選的情況下應該 主動問，不要自己幫使用者決定）。
回傳的paymentUrl要完整、原樣提供給使用者（不要摘要或改寫），並提醒使用者付款完成前 訂單不會出貨。若ok=false，訂單可能已建立但取得付款連結失敗，要把error/note內容如實 告知使用者，不要自行重試建立第二筆訂單。
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | 方案規格，必須跟查詢工具回傳的spec完全一致 | |
| Yes | 使用者的email，必填，訂單憑證與eSIM會寄到這裡 | ||
| phone | No | 使用者的手機號碼，選填 | |
| quantity | Yes | 購買數量，需與使用者確認過的數字一致 | |
| userName | Yes | 使用者的稱呼/姓名，必填，訂單聯絡資料需要，不可留空 | |
| productId | Yes | 方案的productId（GUID字串），必須從查詢工具的結果取得，不可編造 | |
| paymentMethod | No | 付款方式：LinePay，或綠界 (信用卡付款/ATM轉帳/超商條碼)。留空預設LinePay | LinePay |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that this tool creates real orders with real payment flow. It details the consequences, such as order creation and payment link generation, and error handling procedures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core action, followed by numbered prerequisites, and ending with post-call instructions. Every sentence serves a purpose and is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, real financial transaction), the description thoroughly covers preconditions, user communication steps, parameter validation, and response handling. It also explains the meaning of the response fields even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context beyond the schema, such as the need to derive 'spec' and 'productId' from query results and to confirm 'quantity' and 'userName' with the user. This richer explanation aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it establishes a real eSIM order and obtains a payment link. It distinguishes itself from sibling query tools by emphasizing it is not a simulation and involves real payment flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (steps 1-4) and usage instructions, including required user confirmations and data verification. It also instructs what to do if ok=false, preventing retries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_esim_plan_detailAInspect
取得單一方案的完整詳情，包含商品說明（安裝/啟用步驟等）、各規格庫存、購買連結。 適用情境：使用者對某個已知方案想進一步了解安裝方式、使用細節、或確認庫存時。 需要先從search_esim_plans或recommend_esim_plan的結果取得productId，不要自己編造。
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | 方案的productId（GUID字串），從search_esim_plans或recommend_esim_plan的結果取得 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. The description details the output (product description, inventory, purchase link) and implies a read-only query. It does not mention side effects, but given the context, it is safe. The description could be more explicit about being non-destructive, but it is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, no filler. Front-loaded with the main purpose, then scenario, then prerequisite. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose, scenario, prerequisite, and output content. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explicitly instructing that the productId must come from search/recommend tools and not be fabricated. This provides crucial sourcing context that goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '取得單一方案的完整詳情' (get complete details of a single plan) with specific content details (installation steps, inventory, purchase link). It distinguishes itself from siblings by noting it is for a known plan and requires the productId from search/recommend tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when user wants installation details or inventory for a known plan) and provides explicit instruction on how to obtain the required parameter (productId from search_esim_plans or recommend_esim_plan, and not to fabricate it). This provides clear guidance on prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_esim_countriesAInspect
列出一心eSIM目前販售方案覆蓋的所有國家/地區（英文與中文名稱對照，含各國方案數量）。 適用情境：使用者問「你們支援哪些國家」「有賣OO地區的eSIM嗎」；或你準備呼叫 search_esim_plans/recommend_esim_plan，但不確定某國家在系統裡該用什麼名稱表示時， 先呼叫這個工具確認，比用猜的準確。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool is read-only and returns a list with names and plan counts. Could be improved by explicitly stating no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured, front-loading the main function and then providing usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the output (list of countries with names and count). The usage context is fully covered, including prerequisites for other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params), baseline 4. The description provides context for what the output contains, but since there are no parameters, no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all countries/regions covered by eSIM plans, including English/Chinese names and plan counts. It distinguishes from siblings like search_esim_plans and recommend_esim_plan which deal with plans, not countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when user asks about supported countries or to verify country names before calling search/recommend tools. Implies when not to use if country name is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_esim_planAInspect
依旅遊天數與上網用量習慣，推薦最合適的1-3個eSIM方案，並附上購買連結， 是「幫使用者選方案」最好用的工具。 適用情境：使用者詢問出國上網卡、各國eSIM方案、即時發卡服務，並描述了 「要去OO玩幾天」「想找適合的上網方案/漫遊卡」「幫我推薦/挑選eSIM」時優先使用這個， 而不是自己呼叫search_esim_plans後用猜的。
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | 預計使用天數 | |
| country | Yes | 目的地國家，英文或中文皆可，例如 Japan、日本。不確定系統裡的正確名稱時，先呼叫list_esim_countries確認 | |
| usageLevel | No | 用量習慣，留空預設為medium（中度） | medium |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool recommends 1-3 plans and includes purchase links, but does not mention authentication needs, rate limits, or what happens if no plans match. This is adequate but not comprehensive given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in Chinese, no wasted words. The core purpose is front-loaded, and every sentence contributes to understanding the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a recommendation tool with 3 parameters and no output schema, the description covers what the tool returns (1-3 plans with links) and how to use it. It could mention error handling when a country is not found, but the hint to use list_esim_countries mitigates that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline of 3. The description adds value by suggesting to call list_esim_countries if the country name is uncertain, which is a helpful hint beyond schema definitions. It also contextualizes the parameters in relation to travel days and usage habits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends 1-3 eSIM plans based on travel days and data usage, includes purchase links, and positions itself as the best tool for selecting plans. It distinguishes from siblings by directing users to use this tool instead of manually calling search_esim_plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: when users ask about travel SIMs, eSIM plans, or request recommendations. It also suggests using this tool first rather than searching manually. However, it does not explicitly state when to use alternative sibling tools like create_esim_order or get_esim_plan_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_esim_plansAInspect
依國家、方案類型、關鍵字搜尋一心eSIM的商品清單，一次回傳多筆結果讓使用者自己比較。 適用情境：使用者想瀏覽/比較某國家的多個方案，或已經明確講出要哪種類型 （例如指定「總量型」或「每日定量型」）。 如果使用者是描述旅遊情境（去哪個國家玩幾天、上網習慣如何）要你直接建議選哪個， 改用recommend_esim_plan讓它幫忙評分挑選，不要自己從這個工具的結果裡用猜的。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最多回傳幾筆，預設20，避免結果過多 | |
| country | No | 國家名稱，英文或中文皆可，模糊比對，例如 Japan、日本、韓國。不確定系統裡的正確名稱時，先呼叫list_esim_countries確認 | |
| keyword | No | 自由關鍵字，比對商品名稱/描述/規格文字 | |
| planType | No | 方案類型，留空代表不限類型 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly states this is a search/read operation returning multiple results. Lacks detail on permissions or rate limits, but for a benign search tool, the description is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, and includes usage guidance in a few sentences. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, input parameters, and usage context. Does not describe return format explicitly, but given the search nature, it's adequate. References sibling tools for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool searches for eSIM plans by country, plan type, and keyword, returning multiple results for comparison. It clearly distinguishes from sibling tools like recommend_esim_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (browsing/comparing plans) and when-not-to-use (use recommend_esim_plan for travel context recommendations) guidance, with clear differentiation from alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!