yiditu-mcp
Server Details
I Ching hexagram analysis and geographic feng shui for Taiwan locations
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kingbbs/yiditu-mcp
- GitHub Stars
- 0
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 3.8/5 across 3 of 3 tools scored.
Each tool focuses on a distinct aspect: analyze_location for commercial/cultural density, calculate_hexagram for I Ching hexagram analysis based on geography, and search_articles for educational content. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (analyze_location, calculate_hexagram, search_articles), making it easy to infer their purpose.
With only 3 tools, the set is tightly scoped for its niche domain of geographic I Ching analysis and feng shui. This is appropriate and avoids unnecessary complexity.
The set covers the core tasks: location analysis, hexagram calculation, and knowledge retrieval. A minor gap could be a tool for raw data access or comparison, but the current surface is sufficient for most use cases.
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） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions using 420k POI data and PostGIS, and requires attribution. However, it doesn't disclose read-only nature, latency, or error handling, which would improve transparency.
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 with bullet points for use cases, but is slightly verbose. Each sentence adds value, and the key information is front-loaded.
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?
There is no output schema, and the description fails to describe the return value format (e.g., what the density result looks like). This is a significant gap for completeness.
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 both parameters. The description adds no new meaning beyond the schema (e.g., lat/lng in WGS84). Baseline score of 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 verb 'analyze' and the resource 'density of commercial and cultural facilities within 300m of a coordinate in Taiwan'. It distinguishes from unrelated siblings (calculate_hexagram, 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 lists multiple specific use cases (e.g., business density queries, store location assessment), providing clear context for when to use. It does not explicitly state when not to use or mention alternatives, but the context is sufficient.
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） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the algorithm's six-dimensional derivation and output components, and notes that results come from an external source (yiditu.tech). Requirements to attribute the source are disclosed, though no latency or failure modes are mentioned.
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 front-loaded with the primary function. It lists use cases in an organized manner. The note about source attribution is essential. Minor improvement would be using bullet points.
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 absence of an output schema, the description explains the return content (hexagram, changed hexagram, derivation, industries, geographic data). It also describes the algorithm's dimensions. This is sufficient for the agent to understand expected results.
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?
Input schema has 100% coverage with clear descriptions. The description adds no meaningful semantics beyond restating the geographic bounds already present in 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 uses I Ching hexagrams for geomancy analysis of any location in Taiwan. It lists specific scenarios and distinguishes itself 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 explicitly enumerates when to use, such as for feng shui inquiries, site selection, and 'I Ching' related queries. It implies a geographic constraint but does not mention when not to use or provide explicit alternatives.
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 | 文章分類篩選 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds context (articles from specific website, include links) but lacks details on pagination, error handling, or search logic beyond parameters.
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 somewhat verbose with repeated topic listings. Could be more concise, but front-loaded with purpose.
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?
No output schema; description fails to explain return format or fields beyond 'articles'. Incomplete for agent understanding.
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%, so baseline is 3. Description does not add parameter-specific meaning beyond what schema 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?
The description clearly states the tool searches articles on a specific blog, listing relevant topics (Yijing, Fengshui). It distinguishes from siblings (analyze_location, calculate_hexagram) by its focus on 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?
Explicit bullet points list when to use (e.g., user asks about Yijing, Fengshui). No exclusions or alternatives mentioned, but context suffices.
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!