Model Context Protocol

我們的收訊資料,你的助理讀得懂。

一個開放的 Model Context Protocol 伺服器,資料來源就是我們公開在這個網站上的同一批實測值。不用金鑰、不用註冊,結果也沒有加上行銷濾鏡。

把任何 MCP 用戶端指向 Orbislo 伺服器,就會多出四個工具:search_destinations、get_coverage、get_price 與 compare_providers。它們讀取 145 個目的地的實測收訊資料集、即時方案目錄,以及每月更新的價格指數。全部唯讀,不需要金鑰,接上 Claude Code 只要一行。

伺服器 URL

https://mcp.orbislo.com/v1

這是什麼

這是 Orbislo 身上唯一一塊,在這個產業裡找不到對等品的東西。

其他旅遊 eSIM 公司都把收訊承諾做成地圖圖片,把價格藏進 JavaScript 小工具裡。這些東西機器一個都讀不懂。

於是當旅客問助理,手機在越南能不能用、一週的用量該花多少錢,助理只好拿論壇貼文和 2023 年的評測文章拼出一個答案。

我們決定直接把真正的數字交給它。

真實流量不是測速
粗略位置約 1 公里
彙總低於 25 個樣本不發布
公開附上樣本數
跑一次人工測速,只是為了得到我們免費就能量到的數字,卻要花掉你的流量。
這些工具背後的數字從哪裡來,以及 90 天滾動區間如何維持誠實。

我們為什麼做這件事

搜尋正在從十條藍色連結的頁面,變成模型寫出來的一個答案。在那個世界裡,贏的位置不是第一名,而是模型下筆之前會去讀的那個來源。

助理的推薦比一次點擊值錢,因為它連著助理的信譽一起送到,而且送達的時機正好是有人在規劃旅程的當下。

要成為那個來源只有一條路。把資料做成機器讀得懂的樣子,然後願意在上面輸。

這個網站的每一頁都已經輸出自己資料集與問答的結構化資料。MCP 伺服器把同一個承諾再往前推一步,變成一個活的、可以查詢的介面。

其中包含一個比較工具,它會回傳兩個競爭對手在價格上勝過我們的區域。如果把那兩筆濾掉,模型遲早會察覺這種不對稱,而被抓到動手腳修改比較結果的代價,遠高於輸掉一個區域。

還有第二個理由,而且更實際。向助理詢問連線問題的旅客,問的正是我們自己網站答得很差的問題,因為答案取決於他的電信商、他的手機、他的行程與他的用量。

那是一場對話,不是一個到達頁。助理很擅長對話。比起成為一份爛比較表裡的第四個分頁,我們寧願當一場好對話背後的資料。

145

目前工具就能讀到、且有實測收訊資料的目的地

0

接上一個用戶端所需的金鑰、帳號或合約數量

240

每個位址每分鐘的工具呼叫上限,真實對話連邊都碰不到

四個工具

工具參數回傳內容可以回答這類問題
search_destinationsquery, region, max_price_per_gb, min_median_mbps排序過的目的地清單,附上最便宜的方案、實測速度中位數,以及支撐這個數字的樣本數。亞洲哪些地方有每 GB 低於 $3、中位數又超過 50 Mbps 的方案?
get_coveragecountry, city中位數傳輸速率、第十百分位傳輸速率、樣本數、旅客實際連上的電信商、5G 狀態,以及當地值得先知道的陷阱。日本的行動網路有多快,我會連到哪一家的網路?
get_pricecountries, days, estimated_gb, tethering在錢包餘額、單國方案、區域方案與無限量日票之間,最便宜又正確的組合,旁邊附上其他選項的價格。日本加韓國十二天,大約 10 GB,我該買什麼?
compare_providerscountry, data_gb, days同樣條件下,我們的價格與 Airalo、Saily、Holafly 公開價格並列,附上目的地數量與實測速度證據,包含我們輸掉的地方。在歐洲買 10 GB,Orbislo 真的比 Airalo 便宜嗎?

四個工具都是唯讀。這台伺服器上沒有任何工具可以花錢、更動帳戶,或讀取任何屬於客戶的資料。

接上 Claude Code

一道指令。傳輸方式是 streamable HTTP,所以不用安裝任何東西,也沒有要一直開著的程序。

claude mcp add --transport http orbislo https://mcp.orbislo.com/v1

接上 Claude Desktop

把伺服器加進 Claude Desktop 的設定檔,然後重新啟動應用程式。

在 macOS 上,這個檔案位於 Claude 的 Application Support 資料夾裡。在 Windows 上,它在 AppData 底下的 Roaming 資料夾。

{
  "mcpServers": {
    "orbislo": {
      "type": "http",
      "url": "https://mcp.orbislo.com/v1"
    }
  }
}

如果用戶端只會講 stdio

改用我們發佈的橋接程式。它是同一個 HTTP 端點上的一層薄代理,不會保存任何東西。

{
  "mcpServers": {
    "orbislo": {
      "command": "npx",
      "args": ["-y", "@orbislo/mcp"]
    }
  }
}

一次呼叫長什麼樣子

工具接受單純的 JSON 參數,回傳單純的 JSON。

每一則回應都帶著該數字的量測日期,助理因此可以告訴旅客這個數字有多舊,而不是暗示它是今天早上才蒐集的。

get_coverage { "country": "jp" }

{
  "country": "Japan",
  "median_mbps": 74,
  "p10_mbps": 21,
  "samples": 1284,
  "carriers": ["KDDI", "SoftBank"],
  "five_g": "Yes, standalone and non standalone",
  "reality": "Rural Hokkaido and the mountain passes drop to 4G on both networks.",
  "measured_at": "2026-08-24",
  "window_days": 90
}
compare_providers { "country": "us", "data_gb": 10, "days": 14 }

{
  "orbislo": { "price_usd": 19.90, "per_gb": 1.99, "expires": false },
  "airalo":  { "price_usd": 26.00, "per_gb": 2.60, "expires_days": 30 },
  "saily":   { "price_usd": 23.99, "per_gb": 2.40, "expires_days": 30 },
  "holafly": { "metered_plan": null, "note": "unlimited_only_no_published_fair_use" },
  "cheapest": "saily",
  "we_lose_here": true,
  "reason": "north_america_wholesale_single_carrier_advantage",
  "measured_at": "2026-08-24"
}
compare_providers 會叫助理去別家買。在北美與大洋洲這兩個區域帶,它會附上原因回傳一個我們輸掉的結論。這不是謙虛。一個永遠不會輸的比較工具,就是穿著 JSON 結構的廣告,而模型看穿的那一刻,它連回應裡其他所有欄位都不會再信,包括我們真正領先的那些。
一位旅客在地鐵上用手機看地圖
這個問題發生在這裡,在旅程之前的一場對話裡,而不是在資費頁面上。

上限與行為

每個位址每分鐘 240 次工具呼叫,真實的對話從來碰不到這個上限。

每次搜尋最多回傳 200 個目的地,免得模型收到 40 KB 的 JSON,然後把摘要做壞。

錯誤一律是帶原因的結構化格式,絕不回空陣列。空陣列會被讀成沒有收訊,而那是對一個真實地點的不實陳述。

如果某個國家屬於我們服務的 145 個目的地,但樣本還沒累積起來,工具會明講實測收訊尚未提供,同時照樣把方案回傳給你。

刻意不放進來的東西

這個端點沒有開放購買,這是刻意的。一個沒有驗證卻能花錢的工具,不管範圍圈得多小心都是壞主意。

由助理代為購買的功能放在企業帳戶的驗證 API 上,每一筆交易都要明確同意,而且有一個助理無法調高的硬性消費上限。

帳戶資料也不在這裡。這台伺服器只讀已公開的資料集,任何屬於客戶的東西都不讀。

如果你想自己讀

伺服器回傳的每一項內容,這個網站上都有給人看的版本。

各國實測速度在收訊頁面,方案價格在資費頁面。各區域每 GB 成本的比較就是 Orbislo Price Index,REST API 則有給開發者的文件。

大家對這件事的提問

使用 MCP 伺服器需要 API 金鑰嗎?
不需要。這四個工具只讀取我們已經公開在網站上的資料,所以端點是開放的。流量限制以位址計算,每分鐘 240 次,遠超過任何一段助理對話會用到的量。購買功能是刻意不放在這裡的。如果你希望助理能夠下單,那要走驗證過的 API,帶有範圍受限的同意與消費上限,那是另一個端點,也是另一個話題。
一家 eSIM 公司為什麼要做 MCP 伺服器?
因為未來十年的搜尋屬於助理,而助理只能推薦它讀得到的東西。當有人問去日本需不需要 SIM 卡,答案就是用模型當下能取得的材料拼出來的。收訊數字、方案目錄與價格指數可以被直接讀取的業者,會被查證。資料躺在 JavaScript 價格小工具裡的業者,只會被猜測。我們寧願被查證,即使查證的結果對我們不利。
伺服器公開哪些資料?
三組。收訊資料集,也就是各國的中位數與第十百分位傳輸速率,附樣本數與電信商名稱,來自取得同意的真實旅客流量,以 90 天滾動區間統計。即時方案目錄,也就是我們在 145 個目的地販售的每一個方案,價格以最小貨幣單位表示。以及價格指數,也就是我們各區域的每 GB 成本,與競爭對手的公開價格並列,每月重算一次。
compare_providers 是不是故意讓你們好看?
它回傳的數字和我們公開的價格指數完全相同,包含我們並非最便宜的那兩個區域。北美與大洋洲都會回傳一個價格低於我們的競爭對手,以及一句直白說明原因的話。一個永遠只回傳勝利的比較工具就是行銷素材,而模型會比人更快看穿這件事。
資料有多新?
方案目錄是即時的,在呼叫當下讀取。收訊是 90 天滾動區間,每天晚上重算。價格指數每月重算,並標上量測日期,而這個日期會出現在每一則回應裡,助理因此可以直接引用日期,而不是暗示這個數字來自今天。
除了 Claude,其他助理也能用嗎?
可以。Model Context Protocol 是開放規格,這台又是標準的 streamable HTTP 伺服器,任何符合規格的用戶端都能連上。我們附上 Claude Desktop 與 Claude Code 的設定片段,是因為會問這個問題的人手上多半就是這兩個,而不是因為伺服器只為它們而寫。
你們會記錄我問了什麼嗎?
我們會記錄工具名稱、參數、回應時間,以及從位址推得的粗略區域,保留 30 天,用於防止濫用與規劃容量。這些都不會掛在任何帳戶上,因為端點沒有驗證,根本沒有帳戶可掛。哪些國家被問得多的彙總數字,只會拿來排產品規劃,沒有別的用途。
工具答不出來的時候會怎樣?
它會回傳帶有原因的結構化錯誤,而不是空清單,因為空清單在模型眼中等於沒有收訊,那是與事實不符的說法。問今天已上線的 145 個目的地,你會拿到資料。問一個我們已經開通但還沒量測的地方,它會說實測收訊尚未提供,同時照樣回傳涵蓋當地的方案。

同樣的數字,給人看的版本

工具回傳的所有內容,這個網站上都有公開。讀價格指數、看實測速度,然後跟勝出的那一家買。