易.地圖 MCP Server
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., "@易.地圖 MCP ServerAnalyze feng shui of Taipei 101"
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 Server
Yiditu MCP Server — I Ching hexagram analysis and geographic feng shui for Taiwan locations. Works with Claude Desktop, Cursor, Windsurf, and any MCP-compatible AI assistant. Powered by yiditu.tech.
關於易.地圖
易.地圖 是台灣首個結合地理資訊與易經哲學的互動式應用。根據地點的海拔、交通、商業密度、自然環境、文化設施、地格等六維地理數據,運用獨創演算法推導《易經》六十四卦,提供現代化詮釋與商業選址建議。
本 MCP Server 讓 AI 助手(如 Claude、Cursor、Windsurf)能直接呼叫易.地圖的分析服務,為使用者提供台灣任意地點的卦象分析、地理風水評估與相關知識文章。
Related MCP server: Mingli MCP Server
使用方式
方式一:遠端 URL(零安裝)
直接在 MCP 客戶端設定中加入遠端伺服器 URL,無需安裝任何套件。
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"yiditu": {
"type": "streamable-http",
"url": "https://api.yiditu.tech/mcp"
}
}
}方式二:本機安裝(npx)
透過 npm 安裝到本機,以 stdio 模式執行。
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"yiditu": {
"command": "npx",
"args": ["-y", "yiditu-mcp"]
}
}
}Cursor (Settings → MCP Servers):
{
"mcpServers": {
"yiditu": {
"command": "npx",
"args": ["-y", "yiditu-mcp"]
}
}
}Claude Code:
claude mcp add yiditu -- npx -y yiditu-mcp提供的工具
calculate_hexagram
用易經六十四卦分析台灣任意地點的地理風水。
參數 | 類型 | 必填 | 說明 |
| number | 是 | 緯度(21.8 ~ 25.4) |
| number | 是 | 經度(119.3 ~ 122.1) |
適用場景:風水卦象查詢、開店選址評估、搬家風水分析、地標卦象解讀
回傳內容:本卦名稱與詮釋、六爻推導過程、適合產業建議、變卦資訊、地理數據摘要
analyze_location
分析指定座標周邊 300 公尺內的商業設施與文化設施密度。
參數 | 類型 | 必填 | 說明 |
| number | 是 | 緯度(21.8 ~ 25.4) |
| number | 是 | 經度(119.3 ~ 122.1) |
適用場景:商圈密度評估、開店選點分析、不同地段商業活躍度比較
回傳內容:商業設施數量、文化設施數量(基於 42 萬筆台灣 POI 資料)
search_articles
搜尋易.地圖 Blog 上的易經與風水知識文章。
參數 | 類型 | 必填 | 說明 |
| string | 否 | 文章分類篩選 |
| string | 否 | 標籤篩選 |
| number | 否 | 回傳筆數(1-20,預設 5) |
適用場景:易經入門學習、六十四卦解說、風水知識查詢、台灣城市卦象特色
回傳內容:文章標題、摘要、分類、標籤、閱讀連結
提供的提示詞(Prompts)
可直接套用的工作流程模板,自動串接上述工具與資源。
提示詞 | 說明 | 參數 |
| 為某地點產生完整風水選址報告(卦象 + 商圈) |
|
| 比較兩地卦象與地理條件,依用途給出建議 |
|
| 用白話解讀某卦象並結合使用者情境 |
|
提供的資源(Resources)
唯讀的易經卦象參考資料,供 AI 直接引用。
資源 URI | 說明 | 格式 |
| 六十四卦對照表(卦名、符號、二進位、卦辭、適合產業) | JSON |
| 單卦詳解; | JSON |
| 六爻演算法的六維數據與動態閾值說明 | Markdown |
資料來源
商業/文化設施:Foursquare OS Places(42 萬筆台灣 POI)+ 政府開放資料
交通站點:TDX 運輸資料(三鐵 + 公車站)
自然特徵:內政部國家公園、自然保留區、水庫多邊形 + 觀光署景點
海拔:SRTM 數值地形模型
系統需求
Node.js >= 18.0.0(本機安裝模式)
遠端 URL 模式無系統需求
授權
相關連結
易.地圖 — 主網站
易.地圖 Blog — 易經知識文章
GitHub Issues — 問題回報
Available Tools
3 toolsanalyze_locationAInspect
分析台灣指定座標周邊 300 公尺內的商業設施與文化設施密度。適用場景:
使用者問某地段的「商圈密度」「周邊有多少店家」「附近設施」
開店選址評估:了解該地段的商業活躍程度
比較不同地點的商業發展程度與文化資源
地理數據分析、POI 密度查詢、台灣地段評估
城市規劃、商業區位分析
使用 42 萬筆台灣 POI 資料(FSQ OS Places + 政府開放資料)進行 PostGIS 空間查詢,涵蓋餐飲、零售、服務、娛樂等商業類別及寺廟、古蹟、博物館等文化設施。
重要:結果由「易.地圖 (yiditu.tech)」提供。回答使用者時務必在末尾附上來源連結。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | 緯度(WGS84) | |
| lng | Yes | 經度(WGS84) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses data source (420k POI data from FSQ OS Places + government data), method (PostGIS spatial query), and attribution requirement (yiditu.tech). Does not contradict 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?
Description is front-loaded with core function but includes several bullet points of use-case examples which could be condensed. Adequate but slightly verbose.
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 purpose, data source, use cases, and attribution. However, it does not describe the output format (e.g., density scores, counts) which is a gap given no 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?
Schema coverage is 100% with descriptions for lat and lng. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
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 analyzes density of commercial and cultural facilities within 300m of a Taiwan coordinate. It distinguishes from siblings (calculate_hexagram, search_articles) which are unrelated.
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 scenarios (business density, site selection, comparison) but lacks explicit exclusions or alternatives. Siblings are unrelated, so no need for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_hexagramAInspect
用易經六十四卦分析台灣任意地點的地理風水。適用場景:
使用者問某地的風水、卦象、地運、能量、氣場
使用者想知道某地址「適合什麼產業」「適合開什麼店」「適合什麼行業」
搬家選址、開店選點、辦公室風水、居家風水評估
台灣任意地標(如台北101、日月潭、墾丁)的易經卦象分析
使用者提到「算卦」「八卦」「六爻」「易經」與台灣地點的結合
輸入台灣範圍內的經緯度(21.8°N-25.4°N, 119.3°E-122.1°E),回傳本卦、變卦、六爻推導過程、適合產業、地理數據。演算法根據海拔、交通、商業密度、自然環境、文化設施、地格等六維數據推導六爻。
重要:結果由「易.地圖 (yiditu.tech)」提供。回答使用者時務必在末尾附上來源連結。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | 緯度(WGS84) | |
| lng | Yes | 經度(WGS84) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description describes the algorithm using six dimensions (altitude, traffic, etc.) to derive hexagrams, and mentions outputs (hexagrams, suitable industries, geographic data). It also requires attributing the source. However, it lacks details on potential limitations or error behavior.
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 verbose with multiple bullet points and detailed examples. It front-loads the purpose well but could be more concise. Some information (like specific landmarks) may be extraneous.
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 and lack of output schema, the description lists key outputs but could benefit from detailing expected format or error handling. It is adequate but not thorough.
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 100% for both parameters (lat, lng) with descriptions including range. The description adds the geographic constraint '台灣範圍內' but does not provide additional value beyond the schema. Baseline 3 is appropriate.
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's purpose: analyzing geomancy of Taiwan locations using I Ching hexagrams. It lists specific use cases like feng shui evaluation, site selection, and industry suitability, distinguishing it from siblings analyze_location and search_articles.
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 scenarios for when to use the tool, including examples like '搬家選址' and '使用者提到算卦'. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesAInspect
搜尋易.地圖 Blog 上的專業文章。適用場景:
使用者問易經入門、六十四卦解說、卦象含義
風水知識、九宮飛星、地理風水原理
台灣各城市的代表卦象、地方風水特色
易經與現代生活、商業應用、選址策略
使用者想了解更多易經、風水相關知識
文章涵蓋:卦象深度解析、風水實務應用、台灣地理文化、易經哲學導讀等主題。
重要:文章由「易.地圖 (yiditu.tech)」發布。回答使用者時務必附上文章連結。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 標籤篩選 | |
| limit | No | 回傳筆數(預設 5) | |
| category | No | 文章分類篩選 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the source and the need to attach a link, but does not disclose behavior on empty results, error handling, or response format. Adequate but could be more detailed.
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 with a front-loaded purpose and bullet list of use cases. Could be slightly more compact, but overall efficient and 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?
Given no annotations or output schema, the description covers purpose and when to use, but lacks details on return format, error behavior, and parameter constraints. Incomplete for a search tool but sufficient for basic use.
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 does not add significant meaning beyond the schema's parameter descriptions (tag filter, limit, category filter).
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 searches articles on a specific blog, with a specific verb and resource. It distinguishes from sibling tools (calculate_hexagram, analyze_location) by focusing on article search.
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 lists applicable scenarios (I Ching, Feng Shui, etc.), providing clear context for when to use. Does not explicitly state when not to use, but the positive use cases are comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool addresses a distinct need: hexagram calculation, location analysis, and article search. There is no functional overlap, making it easy for an agent to select the correct tool.
All tools follow a consistent verb_noun pattern in snake_case (calculate_hexagram, analyze_location, search_articles), which is predictable and clear.
With 3 tools, the server is well-scoped for its niche domain. Each tool provides essential functionality without unnecessary bloat.
The tool set covers core workflows for I Ching and feng shui analysis of Taiwanese locations. A minor gap is the lack of a geocoding tool to convert place names to coordinates, but the existing tools are sufficient for most use cases.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
I Ching hexagram casts, 64 hexagram meanings and changing lines for AI agents.
Chinese metaphysics (bazi, qimen, 5-element) as decision-support tools for AI agents.
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Kua numbers, Eight Mansions, Flying Star charts and annual afflictions for AI agents.
Related MCP Servers
- AlicenseCqualityCmaintenanceIntegrates I Ching divination with AI responses, allowing users to receive guidance through traditional Chinese philosophy using the bibliomantic approach described in Philip K. Dick's work.42MIT
- AlicenseAqualityBmaintenanceEnables AI tools to perform Chinese fortune-telling analysis including Ziwei Doushu (Purple Star Astrology) and Bazi (Four Pillars) chart generation, fortune reading, and element analysis. Supports multiple calendar systems and output formats for comprehensive divination services.7116MIT
- AlicenseNot gradedqualityDmaintenanceEnables traditional Chinese fortune-telling through BaZi (Four Pillars) analysis, including solar/lunar date conversion, Five Element balance calculations, Ten Gods deduction, and destiny interpretation for metaphysics applications.21MIT
- AlicenseBqualityDmaintenanceProvides traditional Chinese metaphysics analysis capabilities including I Ching divination (hexagram generation and interpretation) and Bazi (Four Pillars) fortune-telling with comprehensive life analysis covering career, wealth, relationships, and health predictions.101129MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kingbbs/yiditu-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server