This server provides natural language access to Taiwan Stock Exchange (TWSE) public data, enabling you to:
Real-time quotes: Fetch live intraday prices for stocks and ETFs (updated ~ every 5 seconds) using ticker codes.
Historical daily data: Retrieve the previous trading day's opening, high, low, closing prices, and trading volume.
ETF snapshots: Get a comprehensive ETF overview—basic info, daily price/volume, and recurring investment popularity ranking, with optional real-time price.
Dataset search: Discover available TWSE datasets by keyword or category tag (e.g., "ETF", "融資", "財務報表").
Dataset description: View full field definitions and schema for any dataset before querying.
Dataset querying: Retrieve data with server-side filtering (by security code, substring matching), field projection, and pagination.
Natural language interaction: Ask questions in plain language; no need to know specific commands, codes, or data fields.
Supports Codex CLI integration to query Taiwan stock data via MCP.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TWSE OpenAPI MCP Server get ETF snapshot for 0056"
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.
English ｜ 繁體中文 ｜ 简体中文 ｜ 日本語 ｜ 한국어
用講話的方式，問你的 AI 台股資料。
台積電現在多少？0056 昨天收多少？這檔 ETF 到底在追什麼指數？ 以前你得自己開網站查，現在直接問 AI 就好。
不用寫程式、不用安裝軟體。你只要複製一個網址，貼進你的 AI 設定裡，大約一分鐘。
MCP 是什麼？ 可以想成幫 AI 裝外掛。AI 本身不會查台股， 裝上這個外掛之後，它就多了這項技能。（MCP 是這種外掛的通用規格， Claude、ChatGPT 等等都支援。）
這是一個個人佛心專案，資料全部來自臺灣證券交易所與臺灣期貨交易所的公開來源。免費使用。
裝好之後，直接用中文問就可以，例如：
「台積電現在多少？」 —— 盤中的即時報價，一次問好幾檔也行。
「0050 昨天收盤多少、量多大？」 —— 前一個交易日的開盤、最高、最低、收盤、成交量。
「0056 這檔 ETF 到底是什麼？」 —— 追蹤哪個指數、多少人在定期定額，還會提醒你哪些數字不能當真。
「台指期昨天收在哪？」 —— 期貨與選擇權的每日行情、三大法人、未平倉，交易所公布的都查得到。
「證交所有沒有 ⋯⋯ 的資料？」 —— 幫你在兩百多張公開報表裡找到對的那一張。
你不需要記任何指令或代號，講人話就好，AI 會自己去查。
Related MCP server: deepq-financial-toolkit
以 Claude 為例（網頁版 claude.ai 或桌面版都一樣）。 免費方案就可以用——免費方案能加 1 個外掛，而你正好只需要 1 個。 （依據 Anthropic 官方說明，2026 年 8 月查證；方案規則可能變動。）
在畫面左下角你的名字上點一下 → 選 Settings（設定） → 在左側選單找到 Connectors（連接器）。
按 「+ Add custom connector（新增自訂連接器）」，會跳出一個小視窗要你填兩格。
名稱（Name） 隨你取，例如 台股。
網址（URL） 貼下面這一行——把游標移到框上，右上角會出現複製按鈕：
https://twse-mcp.taux.io/mcp按 Add 就完成了。不用帳號、不用密碼、不用付費。
回到聊天畫面，開一個新對話，點輸入框旁邊的 「+」 → Connectors， 把剛才加的「台股」打開。
問它一句：
用台股連接器查一下 0050 現在多少？
如果它回你一個具體的價格數字（例如「0050 目前約 97.15 元」），就成功了。 如果它說查不到、或開始上網搜尋，看下一段。
AI 說查不到，或跑去上網搜尋 最常見的原因是連接器沒有打開，或是設定完沒有開新對話。 先開一個新對話，點「+」確認「台股」是開著的。 如果還是不行，就明白告訴它：「用台股連接器查 0056」——直接點名通常就會用了。
上櫃股票查不到完整資料 這不是壞掉，是限制。上櫃的股票（例如 6488 環球晶、00679B 元大美債20年） 查得到現在的價格、今天的開高低、昨天的收盤、成交量， 但查不到更早的歷史行情、統計報表，也做不出 ETF 的完整概況。 詳見下面「有些查得到、有些查不到」。
找不到 Connectors 這個設定 如果你用的是公司或團隊的帳號，通常要管理員先加，成員才能開啟。 個人帳號（含免費方案）則是自己就能加。
除了直接講人話問，這個服務也內建三個快捷指令，會跟著連接器自動出現——不用另外裝東西。
指令 | 做什麼 | 帶什麼 |
| 不知道該查哪張表時，用關鍵字找出對的那一個 | 關鍵字，例如「三大法人」 |
| 一次看完一檔上市 ETF 的基本資料、前一交易日價量與定期定額熱度 | ETF 代號，例如 |
| 查期貨或選擇權的每日行情 | 契約代號或商品名，例如 |
在 Claude Desktop：點輸入框旁的 「+」，在選單裡找到它們。
在 Claude Code：輸入 / 就會列出來，格式是 /mcp__twse__find_dataset。
不用也沒關係——它們只是把常見的問法先寫好，直接用中文問一樣有效。
你問：「0056 現在多少？」
AI 大概會回： 0056（元大高股息）目前約 48.19 元，比昨天收盤（50.00）跌約 3.6%， 今天在 48.14～49.26 之間。
（數字示意，實際以你查詢當下為準）
你問：「0050 昨天收盤多少、成交量多大？」
AI 大概會回： 0050（元大台灣50）前一交易日收 97.15 元， 全日成交約 4.0 萬張，開 98.35、最高 98.35、最低 96.90。
（示意）
你問：「幫我看 0056 這檔 ETF 的完整概況。」
AI 大概會回： 0056 是追蹤「臺灣高股息指數」的 ETF， 定期定額很熱門（排在前段班），市值粗估約 7,100 億元—— 並提醒你：這個粗估是用收盤價 ×發行單位數算的，不等於基金實際規模。
（示意）
你問：「證交所有沒有定期定額交易戶數的資料？」
AI 大概會回： 有，證交所有「定期定額交易戶數統計排行月報表」， 我可以幫你查某檔的排名與交易戶數。
一次問多檔也可以，例如：「幫我一次看 0050、0056、台積電的即時報價。」
上市的股票與 ETF（代號多是 4 碼，例如 2330 台積電、0050）——上面說的全部都查得到。
上櫃的股票與 ETF（例如 6488 環球晶、00679B 元大美債20年）——只查得到即時報價那一組數字： 現在的價格、今天的開盤最高最低、昨天的收盤、成交量。 查不到更早的歷史行情與統計報表，也做不出 ETF 完整概況（追蹤指數、規模那些）。
原因是上櫃的報表資料來源網站，會擋掉從雲端主機來的連線，而這個服務就跑在雲端上。 即時報價走的是另一個沒有擋的來源，所以不受影響——昨收也是跟著即時報價一起來的。 （我們正在找人幫忙解決這件事，見下面「一起來改進」。）
這是個人佛心專案。 我盡量讓它一直開著，但可能偶爾限流、臨時維護、或未來換網址——不保證隨時都在。
即時報價是「盡量即時」。 它來自證交所的網頁介面，可能有幾秒到幾分鐘延遲、偶爾抓不到，或跟你券商看到的報價略有出入。
資料僅供參考，不是投資建議。 數字可能有誤或延遲，下單前請自己再向官方或券商確認，投資盈虧請自行負責。
除了即時報價，其他資料最多可能慢一小時。 為了不一直去打證交所，各類報表會快取一小時；盤中價格不快取，永遠是當下抓的。
不用登入，也不會知道你查了什麼。 你查的內容會經過本服務去代理證交所的公開資料。目前為了統計還有多少人用舊版連線方式，會記錄你的 AI 工具種類與連線協定版本——不含你問的問題，統計完就會移除。
臺灣證券交易所 2026 臺灣證券交易所 OpenAPI
金融監督管理委員會證券期貨局 2026 臺灣期貨交易所 OAS
此開放資料依政府資料開放授權條款 (Open Government Data License) 進行公眾釋出，使用者於遵守本條款各項規定之前提下，得利用之。
政府資料開放授權條款：https://data.gov.tw/license
一個例外：盤中即時報價來自證交所基本市況報導站（
mis.twse.com.tw），該站未登錄於政府資料開放平臺，不在上述授權範圍內。
本服務僅為代理與轉換，不對資料正確性負責；引用時請一併標示上述來源。
這是開源專案，歡迎一起把它變好——原始碼在 GitHub。
任何形式的參與都歡迎：用起來覺得怪、查不到你想要的資料、或希望它多會一件事， 都可以直接開一個 issue 說； 會寫程式的話也歡迎直接送 PR。
目前最需要幫忙的一件事：讓上櫃資料也能查。 上櫃的資料來源（櫃買中心）會封鎖雲端伺服器的連線——我們實測過，從台灣的一般網路連得上， 但從服務所在的雲端就被擋掉，而且不是換個標頭就能繞過的。要解決得有一台在台灣、 能長期運作的機器幫忙轉送。如果你手上剛好有這樣的環境、或知道更好的做法， 非常歡迎來聊聊。
以下給習慣用終端機或其他 AI 工具的人，一般使用者可以略過。
Claude Code
claude mcp add twse --transport http https://twse-mcp.taux.io/mcpCodex（OpenAI）
codex mcp add twse --url https://twse-mcp.taux.io/mcp其他支援遠端 MCP 的工具，把這組連線資訊填進它的設定：
項目 | 值 |
網址 |
|
連線方式 | Streamable HTTP（遠端 MCP），新舊版 MCP 協定都支援 |
認證 | 不需要 |
各家設定檔的欄位名稱不太一樣，請對應到「Streamable HTTP」那一種，不要選成舊的 SSE。
一次取得單一上市 ETF 的完整概況：基本資料 + 當日價量 + 定期定額熱度。
合併三張證交所的表並行查詢，比分別呼叫 twse_get_dataset 快也不易出錯。 任何一段查不到都會標成 null 並記在 caveats，不會整個失敗。
Args: code: ETF 代號，例如 "0056"、"0050"、"00878"。 include_realtime: 是否附上盤中即時報價（盤後或休市時可能為空）。
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| include_realtime | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parallel query of three tables, partial failure behavior (marks null, records caveats), and that include_realtime may be empty after hours. No annotations provided, so description carries full burden, and it excels.
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?
Efficient structure: summary line, comparison, behavior note, then args. No wasted words, front-loaded key info.
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 2 parameters, no annotations, and existing output schema, the description covers purpose, behavior, and parameters adequately. No missing critical 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 coverage is 0%, but the description explains code as ETF symbol with examples and include_realtime as real-time quote inclusion with caveat. Adds significant value, though could specify code format further.
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 retrieves a complete snapshot of a single ETF, merging three TWSE tables. The verb '取得' (get) and resource 'ETF 完整概況' are specific, and it distinguishes from siblings by noting it's faster than separate calls to twse_get_dataset.
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?
Explicit guidance: use when needing a comprehensive ETF overview in one call, comparing favorably to twse_get_dataset. Also notes partial failure handling (null + caveats), making it resilient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看某個資料集的完整欄位定義，取資料前用來確認要過濾／投影哪些欄位。
Args: dataset_id: 來自 twse_search_datasets 的代號，例如 "exchangeReport/STOCK_DAY_ALL"。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explains the tool returns field definitions and implies read-only behavior, but does not explicitly state that it is non-destructive or discuss auth/rate limits.
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 very concise with two clear sentences. The first sentence states the purpose, and the second explains the parameter usage. No extraneous information.
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?
With an output schema provided, the description does not need to explain return values. It covers the tool's role in the workflow (use before fetching data) and is complete for a simple schema-inspection tool.
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?
The only parameter dataset_id is described with a source (來自 twse_search_datasets) and an example ('exchangeReport/STOCK_DAY_ALL'), adding significant value beyond the schema's type-only definition.
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 is for viewing complete field definitions of a dataset, with a specific verb ('查看') and resource ('資料集的完整欄位定義'). It distinguishes itself from siblings like twse_search_datasets (searching) and twse_get_dataset (presumably fetching data).
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 explicitly says to use it before fetching data to confirm which fields to filter/project (取資料前用來確認要過濾／投影哪些欄位). It provides clear context but does not include when-not-to-use or explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得證交所資料集內容，支援伺服器端過濾、欄位投影與分頁。
證交所每個 endpoint 都是一次回整份資料（可能上千筆），所以務必用 code / match / fields 縮小範圍，不要無條件拉全部。
Args: dataset_id: 資料集代號，例如 "exchangeReport/STOCK_DAY_ALL"。 code: 證券／基金代號，例如 "0050"。會自動偵測該表的代號欄位名稱。 match: 其他欄位的子字串過濾，例如 {"基金類型": "ETF"}。 fields: 只回傳這些欄位，例如 ["Code", "Name", "ClosingPrice"]。 limit: 回傳筆數上限（硬上限 200）。 offset: 分頁位移。
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| limit | No | ||
| match | No | ||
| fields | No | ||
| offset | No | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses server-side filtering, a hard limit of 200 for limit parameter, and auto-detection of code column name. However, it omits error handling, permissions, rate limits, or idempotency, so it's adequate but not comprehensive.
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 concise and well-structured: a one-sentence purpose, a crucial usage warning, then a bullet list of args. Every sentence adds value with no redundancy.
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?
The description covers core usage, filtering, and pagination. Since an output schema exists, return format is not needed. It lacks error handling or prerequisites, but for a data retrieval tool with good parameter docs, it's nearly complete.
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 0%, so the description fully compensates. It explains all 6 parameters with concrete examples (e.g., dataset_id like 'exchangeReport/STOCK_DAY_ALL', code like '0050', match as dict, fields as array), adding meaning beyond the schema's type-only definitions.
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 '取得證交所資料集內容' (get TWSE dataset content) with support for server-side filtering, field projection, and pagination. It distinguishes from siblings like twse_search_datasets (search) and twse_describe_dataset (describe structure) by focusing on retrieving actual data rows.
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 second paragraph explicitly advises using code/match/fields to narrow scope and warns against unconditional full pulls ('不要無條件拉全部'). It provides examples for each parameter and implies when to use filtering, fulfilling the when-to-use and when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得盤中即時報價（約 5 秒更新一次）。
OpenAPI 只有前一交易日資料，要當下的價格得走基本市況報導站。 ETF 與上市股票用 market="tse"，上櫃用 "otc"。
Args: codes: 代號清單，例如 ["0050", "0056", "2330"]。 market: "tse"（上市）或 "otc"（上櫃）。
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | ||
| market | No | tse |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. Discloses update frequency and data source (basic market station vs OpenAPI). Lacks details on rate limits, authentication, or error handling.
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?
Concise three-sentence description plus an Args block. Efficiently conveys purpose, usage, and parameters. Could be slightly more streamlined but minimal waste.
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 output schema, description covers purpose, usage, parameters, and update frequency. No need to detail return values. Adequately complete.
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 coverage is 0%, but description adds meaning: codes are stock symbols with examples, market is exchange type with default. Compensates for missing schema descriptions.
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 it retrieves real-time stock quotes with approx 5-second updates, contrasting with OpenAPI's previous-day data. It distinguishes from sibling tools (datasets, ETF snapshot) by focusing on real-time quotes.
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 context for when to use (real-time vs historical), and guidance on market parameter (tse vs otc). Does not explicitly exclude alternatives or mention when not to use, but context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋證交所 OpenAPI 有哪些資料集可用。取資料前先用這個找 dataset_id。
會比對資料集代號、中文說明與欄位名稱。
Args: query: 關鍵字，例如 "ETF"、"基金"、"融資"、"本益比"、"月營收"。留空列出全部。 tag: 依分類過濾，例如 "證券交易"、"公司治理"、"財務報表"、"指數"、"券商資料"。 limit: 最多回傳幾筆（預設 25）。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It explains the search behavior, parameter effects, and that it matches codes/descriptions/field names. No destructive or side effects mentioned, but as a read operation this is acceptable. It lacks rate limit or permission info, but not critical.
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: two sentences plus parameter list. Front-loaded with purpose, each sentence is necessary. No fluff or redundancy.
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 an output schema exists, return values need not be described. The description covers purpose, parameters, and usage context (TWSE OpenAPI). Could mention that results include dataset_id, but output schema handles 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 0%, yet the description adds rich meaning: query with examples (ETF, 基金), tag with examples (證券交易, 公司治理), and limit with default 25. This fully compensates for missing schema descriptions and helps agents understand 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 the tool searches TWSE OpenAPI datasets to find dataset_id before fetching data. It specifies matching against codes, descriptions, and field names. This distinguishes it from sibling tools (describe, get, realtime quote, snapshot) which serve different purposes.
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 advises using this tool before fetching data and provides parameter usage details (e.g., empty query lists all, tag filters by category). It does not explicitly mention when not to use it or alternatives, but the context and sibling names imply search is for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0etf_snapshottwse_describe_datasettwse_get_datasettwse_realtime_quotetwse_search_datasetsEach tool has a clearly distinct purpose: searching datasets, describing schemas, fetching data with filters, realtime quotes, and a specialized ETF snapshot. No overlap in functionality.
Most tools follow a 'twse_verb_noun' pattern, but 'etf_snapshot' uses a different prefix and 'twse_realtime_quote' is adjective-noun instead of verb-noun. Minor inconsistency but still largely predictable.
With 5 tools, the set is well-scoped for interacting with the TWSE OpenAPI. Each tool earns its place, covering search, schema inspection, data retrieval, realtime quotes, and a specialized snapshot.
Covers the main workflows: discovering datasets, understanding schemas, fetching filtered data, and realtime quotes. Missing explicit date-range filtering and a generic stock snapshot, but the ETF snapshot fills part of that gap. Minor gaps but sufficient for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Taiwan finance open data: ETF, funds, TAIEX, sentiment, business climate, FX. Free & read-only.
Official-source financial data for AI agents: Korea, US, Taiwan, Japan, Europe. 37 tools, free tier.
Taiwan stock market data (TWMD): official-source, point-in-time-safe datasets via read-only tools.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/taux-io/twse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
