This server provides a compliant navigation layer for discovering, browsing, and reading public Taiwanese educational resources through three core tools:
discover_education_sources: Find official Taiwanese educational platforms (e.g., NTU OCW, 均一教育平台, 教育大市集) by keyword, education stage (小學/國中/高中/大學/技職/全階段), and subject. Returns up to 5 ranked platforms with URLs, categories, and applicable stages — prioritizing a built-in catalog of 10 verified platforms before falling back to the TWCampus directory.
browse_education_source: Search for learning resources (courses, materials) on a specific platform by name or URL. Returns up to 5 results per query with title, URL, summary, and source info — without attempting login or bypassing access controls.
read_education_resource: Extract key metadata from a single public resource page, including title, summary (≤500 characters), publisher, education stage, subject, and license. Does not store full content.
Compliance safeguards include rate limiting (3 requests/min per domain), a maximum of 2 pages per request, no recursive crawling or full-text storage, and structured error responses (rate_limited, policy_violated, source_unavailable, login_required) for graceful error handling.
Click on "Deploy 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., "@opendata-campus-mcp find NTU open courses on information management"
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.
教育資源導航 MCP — 以 TWCampus 作為目錄入口，路由至台灣官方教育平台，即時搜尋並讀取公開學習資源。
An MCP server that lets LLMs navigate Taiwan's official education platforms without guessing URLs or scraping entire sites. It routes queries through a compliant, auditable layer — discover the right platform, browse it for resources, then read a single summary — with rate limits and access-control guardrails enforced at the domain level.
讓 LLM 不用自己亂猜網址、也不會把整個教育網站爬回來，而是經由一個合規、可稽核的導航層：先從本地目錄（必要時補 TWCampus）找到正確的官方平台 → 在平台上搜尋 → 讀取單一資源摘要。
完整內容依主題拆分於 docs/，依需求檢索：
文件 | 內容 |
安裝步驟、在 Claude Desktop / Claude Code 中設定、測試指令 | |
| |
分層架構圖、運作原理、專案結構、SDD 規格、擴充指南 | |
內建 10 個平台目錄、來源 live 健康度實測 | |
瀏覽政策護欄、已知問題、合規聲明 | |
Playwright 後備取捨、Browserbase / 雲端無頭瀏覽服務評估 |
Related MCP server: taiwan-data-hub
flowchart LR
A[Claude / Agent] --> D[discover 找平台]
D --> B[browse 搜資源]
B --> R[read 讀摘要]
D -.-> L[(本地目錄)]
B --> G[合規護欄]三段式導航：discover（找平台）→ browse（搜資源）→ read（讀摘要），對應 LLM 真實的查找心智流程。
本地目錄優先：內建 10 個已驗證的台灣官方教育平台，先查本地、不足才補 TWCampus，最小化對 TWCampus 的請求。
教育大市集官方 API：教育大市集 使用 OFFICIAL_API；未設定 EDUMARKET_API_KEY 時在 HTTP request 前回傳 source_unavailable，不降級到已知失效的 web search；設定 key 後回傳官方 API 的結構化學制與領域欄位（見設定說明）。
CIRN canonical host：CIRN 使用已驗證的 https://cirn.k12ea.gov.tw，來源目錄與搜尋 URL 保持一致；各來源的最新 smoke 狀態見來源健康度。
共用 runtime assembly：MCP server、live smoke 與教育大市集 E2E 共用同一份 adapter registry，並在 server lifespan 結束時關閉由 runtime 擁有的 HTTP clients。
合規護欄寫死於 domain 層：每域 3 req/min、每次請求最多 2 頁、不排程、不遞迴、不存全文、不繞過存取控制。
乾淨分層 + DI 邊界：contracts.py 定義所有跨層 DTO / Protocol，新增平台或存取策略不需動到核心邏輯。
降級不中斷：TWCampus 故障時靜默降級回本地目錄，工具永遠回傳結構化結果或明確的 error 物件。
SDD 驅動：附 DDD 領域模型（spec/erm.dbml）與 5 組 BDD Gherkin feature，規格即文件。
需求：Python 3.11+
git clone https://github.com/trionnemesis/opendataCampus-MCP.git
cd opendataCampus-MCP
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"接入 Claude Code：
claude mcp add opendata-campus -- /絕對路徑/opendataCampus-MCP/.venv/bin/opendata-campus-mcp其他 client 設定、Playwright 後備安裝、測試指令見 安裝與設定。
工具 | 用途 |
| 找到相關官方教育平台 |
| 在指定平台搜尋學習資源 |
| 讀取單一資源頁面摘要 |
| 找升學考古題（CEEC 學測 / 分科測驗）的官方下載連結 |
參數細節、回傳範例與錯誤回傳見 MCP 工具 API。
護欄寫死於 domain/browser_policy.py，無法由請求參數放寬：
政策 | 值 |
每次請求最多頁數 | 2 頁 |
同域每分鐘請求上限 | 3 次（滑動視窗，per-domain） |
排程爬取 / 遞迴導航 / 全文儲存 / 向量索引 | 全部停用 |
無頭瀏覽器（Playwright） | 預設 停用，需明確 |
登入 / 繞過存取控制 | 永不嘗試 |
本工具僅存取公開教育資源並遵守來源服務條款；TWCampus 僅作路由目錄，所有抓取均由使用者即時查詢觸發。完整聲明與已知限制見 合規與限制。
g0VMCP — 政府採購標案情報 MCP
healthcare-opendata-mcp — 醫療健保開放資料 MCP
在指定官方教育平台上搜尋學習資源。
source：平台名稱（如「教育大市集」）或官方 URL。 回傳 results 列表，每筆含 title、url、summary、source_name、source_url。 max_results 上限 5；不嘗試登入或繞過任何存取控制。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: returns a results list with specific fields, max_results upper limit of 5, and explicitly states it will not attempt login or bypass access controls. This is 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, containing only relevant sentences without fluff. It uses a bullet-like format for clarity, making it easy to parse.
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 tool has 3 parameters, 2 required, an output schema (so return values are covered), and no annotations. The description covers constraints (max_results limit, no auth) and output structure. It could be more complete by noting error handling or source validation, but overall sufficient for operation.
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%, so description must compensate. It explains 'source' with an example (platform name or URL) but does not clarify the 'query' parameter beyond its type. 'max_results' is mentioned as having an upper limit of 5, but no additional semantic detail.
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 verb (搜尋/search) and resource (學習資源/learning resources) on official education platforms. It distinguishes from siblings: discover_education_sources (discovering sources) and read_education_resource (reading a specific resource).
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 a constraint (no login or bypass access control) implying use only for public resources. However, it lacks explicit guidance on when to use this tool versus its siblings (discover_education_sources, read_education_resource).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
從 TWCampus 目錄找到相關官方教育平台（最多 max_sources 個）。
education_stage 可為：國小 / 國中 / 高中 / 大學 / 技職 / 全階段 回傳每個平台的 name、official_url、categories、directory_source。 TWCampus 僅作路由目錄，不作為資源倉庫；本地目錄優先。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| education_stage | No | ||
| subject | No | ||
| max_sources | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that results are fetched from TWCampus directory, prioritizes local directory, and clarifies TWCampus is not a resource warehouse but a router. No side effects mentioned, but read-only nature is implied.
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?
Four sentences with no redundancy. Front-loads purpose, then provides parameter details and behavioral notes efficiently.
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 has 4 parameters (simple types), no enums, and an output schema (not shown), the description covers core purpose, return fields, and parameter hints. Misses explanation for subject param and error handling, but overall adequate.
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 description must compensate. It explains education_stage possibilities, implies query is a search term, and mentions max_sources limit. However, subject parameter is not explained, leaving ambiguity.
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 the tool discovers official education platforms from TWCampus directory, up to max_sources. It specifies the return fields (name, official_url, categories, directory_source) and distinguishes itself from siblings (browse_education_source, read_education_resource) by focusing on discovery and routing.
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?
Description provides possible values for education_stage (國小, 國中, 高中, 大學, 技職, 全階段) and notes TWCampus is only a routing directory, implying when to use. However, it lacks explicit when-not-to-use guidance or alternatives beyond the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
讀取單一公開教育資源頁面的關鍵資訊（摘要，不儲存全文）。
extract 可指定欄位：title / summary / publisher / education_stage / subject / license 回傳物件包含 url 來源欄位；summary 不超過 500 字元。 不嘗試登入或繞過任何存取控制。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| extract | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the tool does not attempt to log in or bypass access controls, returns a summary of up to 500 characters, and does not store full text. This provides good behavioral insight, though lacks details like error handling or 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 concise, front-loaded with the main purpose, and uses bullet-like enumeration for parameters and behavior. Every sentence is substantive with no superfluous text.
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 presence of an output schema (not shown), the description appropriately covers the key aspects: input parameters, return object fields, and access behavior. It could mention potential error scenarios but is largely complete for a simple read 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?
Schema description coverage is 0%, so the description must add value. It explains the 'extract' parameter with allowed field values (title, summary, publisher, etc.) and notes summary length limit. This adds substantial meaning beyond the schema's bare 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?
Description clearly states the tool reads key information (summary, not full text) from a single public education resource page. It specifies that it is for reading, distinguishing it from browsing or discovering resources. The verb and resource are specific.
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 implies usage for reading a specific page's info but does not explicitly compare with sibling tools (browse_education_source, discover_education_sources) or provide when-not-to-use guidance. Usage context is inferred, not stated.
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.
v0.1.0browse_education_sourcediscover_education_sourcesread_education_resourceScored across 3 tools
Each tool serves a clearly distinct purpose: browsing resources on a specific platform, discovering available platforms, and reading a single resource's details. There is no overlap.
All tools follow a consistent verb_noun pattern with snake_case: browse_education_source, discover_education_sources, read_education_resource.
Three tools is on the low side but appropriate for the focused scope of navigating educational open data sources from TWCampus. Could be slightly expanded, but current count is reasonable.
The set covers the basic workflow: discover sources, browse resources within a source, and read details of a resource. Minor gaps like aggregating searches across sources or listing all resources from a source without query are absent but not critical.
台灣繁中：一個 MCP 端點串接 19 個台灣資料站工具，並可搜尋 MCP 伺服器與 x402 付費 API。
Taiwan legal research MCP: 判決書、全國法規、釋字/憲判與立法歷程查詢，12 個工具，回應均附官方出處 URL。
Hosted MCP server for finding authoritative primary data sources and official portals.
Read-only MCP: search & read a Traditional Chinese (zh-TW) Taiwan community forum (PTT-style).