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-twfood Average cabbage price this week?"
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.
An MCP (Model Context Protocol) server for twfood.cc — Taiwan's agricultural wholesale market real-time price data platform. Provides 6 AI-callable tools to search products and query daily, weekly, monthly, yearly trade data and cross-market price comparisons.
6 MCP tools — Search products, query trade data at 4 time granularities, cross-market comparison
No authentication — Uses public twfood.cc APIs, no credentials needed
Historical data — Yearly summaries back to 1996
16+ wholesale markets — Cross-market volume and price comparison
2,000+ products — Vegetables, fruits, flowers, imported items
Related MCP server: korean-agriculture-mcp
Python 3.10+
No API credentials required (public data)
pip install mcp-twfooduvx mcp-twfoodgit clone https://github.com/asgard-ai-platform/mcp-twfood.git
cd mcp-twfood
uv venv && source .venv/bin/activate
uv pip install -e .# Test connection
python scripts/auth/test_connection.py
# Run all tool tests
python tests/test_all_tools.py
# Start MCP server
python mcp_server.pyAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"twfood": {
"command": "python",
"args": ["/path/to/mcp-twfood/mcp_server.py"],
"env": {
"PYTHONPATH": "/path/to/mcp-twfood"
}
}
}
}The .mcp.json file is auto-discovered when you open the project directory.
Add to Cursor MCP settings:
{
"mcpServers": {
"twfood": {
"command": "python",
"args": ["/path/to/mcp-twfood/mcp_server.py"],
"env": {
"PYTHONPATH": "/path/to/mcp-twfood"
}
}
}
}You: 我想知道上週高麗菜的批發價格
AI calls:
search_products(keyword="高麗菜")Found item code LA1. Then:
get_weekly_trades(item_code="LA1", start_date="2026/03/24")Result: SUCCESS — Last week (week 14) cabbage averaged 6.47 TWD/kg, total volume 4,041,510 kg. Price has been gradually rising from 5.76 in early March.
You: 全台各批發市場的高麗菜行情比較
AI calls:
get_market_history(item_code="LA1")Result: SUCCESS — Returns volume and price time series for 17 markets. For example, 台北二 averages 7.2 TWD/kg while 西螺鎮 averages 5.1 TWD/kg — regional price differences clearly visible.
You: 三月份金鑽鳳梨每天的批發價多少？
AI calls:
get_daily_trades(item_code="B2", start_date="2026/03/01")Result: SUCCESS — 33 daily records. March 1: avg 28.02, high 36.75, low 20.02 TWD/kg with volume 126,913 kg. Prices fluctuated between 20–37 TWD/kg range throughout the month.
You: 草莓歷年來的價格變化？
AI calls:
get_yearly_trades(item_code="N1")Result: SUCCESS — 31 years of data since 1996. Prices rose from ~40 TWD/kg in the early 2000s to 80–98 TWD/kg in recent years (2022: 97.8, 2023: 80.73, 2024: 81.86, 2025: 94.23 TWD/kg).
You: 香蕉近一年的月度走勢
AI calls:
get_monthly_trades(item_code="A1", start_date="2025/04/01")Result: SUCCESS — 12 monthly summaries showing seasonal price and volume patterns. Useful for understanding supply cycles and planning purchasing.
You: 有哪些鳳梨品種？
AI calls:
search_products(keyword="鳳梨")Result: SUCCESS — Found 7 varieties: 鳳梨-開英 (B1), 鳳梨-金鑽鳳梨 (B2), 鳳梨-香水鳳梨 (B3), 鳳梨-鳳梨花 (B4), 鳳梨-蜜鳳梨 (B5), 鳳梨-其他 (B9), plus 釋迦-鳳梨釋迦 (32).
You: 最近蒜頭貴不貴？幫我查一下
AI calls:
search_products(keyword="蒜頭")Found 大蒜-蒜頭 with code SG5. Then:
get_daily_trades(item_code="SG5", start_date="2026/03/01")Result: SUCCESS — Returns daily prices so you can compare current prices against recent trends and decide whether to buy now or wait.
You: 哪個批發市場的高麗菜最便宜？
AI calls:
get_market_history(item_code="LA1")Result: SUCCESS — AI analyzes the price time series across 17 markets and identifies the markets with consistently lower prices. Southern and central markets (e.g., 西螺鎮, 溪湖鎮) tend to have lower prices than 台北二.
Tool | Description | Parameters |
| Search 2,000+ products by name or code |
|
| Daily trade data (volume, avg/high/low price) |
|
| Weekly trade summaries |
|
| Monthly trade summaries |
|
| Yearly trade summaries (back to 1996) |
|
| Cross-market volume & price comparison (~17 markets) |
|
Category | Prefix | Example |
Leafy vegetables |
| LA1 (Cabbage/高麗菜) |
Legumes |
| FB1 |
Seasonings |
| SA3 |
Vegetable fruits |
| FJ3 |
Stem vegetables |
| SB2 |
Fruits | Various | A1 (Banana), B2 (Pineapple), P1 (Guava), N1 (Strawberry) |
Roses |
| FR102 |
Imported roses |
| IR101 |
Use search_products to find the exact item code for any product.
stdio (JSON-RPC 2.0)
→ mcp_server.py (entry point)
→ app.py (FastMCP singleton)
→ tools/twfood_tools.py (@mcp.tool() — 6 tools)
→ connectors/rest_client.py (HTTP GET with retry)
→ auth/none.py (no auth — public API)
→ config/settings.py (twfood.cc endpoints)This project uses GitHub Actions for automated PyPI publishing.
PyPI Trusted Publisher — Go to pypi.org/manage/account/publishing and add:
PyPI project name: mcp-twfood
Owner: asgard-ai-platform
Repository: mcp-twfood
Workflow name: publish.yml
Environment name: pypi
GitHub Environment — Repo Settings > Environments > New environment named pypi
# Tag and create release — triggers publish workflow
gh release create v0.1.0 --title "v0.1.0 - Initial Release" --notes "Initial release with 6 tools for Taiwan agricultural wholesale market data"See CONTRIBUTING.md.
This MCP server retrieves data from twfood.cc (當季好蔬果), a Taiwan agricultural wholesale market real-time price data platform that combines big data and data visualization technologies.
Website: https://www.twfood.cc/
Data license: Price-related charts are licensed under Creative Commons BY-NC-ND 4.0 International
Data source: Taiwan wholesale market transaction records (vegetables, fruits, flowers)
We sincerely thank the twfood.cc team for making this valuable agricultural market data publicly accessible. Their work enables transparency in Taiwan's agricultural wholesale market and benefits farmers, traders, researchers, and consumers.
Note: This project is an independent open-source MCP server and is not officially affiliated with or endorsed by twfood.cc. Please respect the data license terms when using the data retrieved through this server.
MIT License — see LICENSE for details.
The MIT license applies to the source code of this MCP server only. The agricultural market data accessed through twfood.cc is subject to its own CC BY-NC-ND 4.0 license terms.
This server is part of the Asgard AI Platform open-source ecosystem, connecting AI to real-world services across e-commerce, finance, government data, IoT, social media, and more.
Get daily wholesale market trade data for an agricultural product. Returns transaction volume (kg), average/high/low prices (TWD/kg) per day.
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Product item code (e.g., 'LA1' for lettuce, 'B2' for pineapple) | |
| start_date | Yes | Start date in YYYY/MM/DD format (e.g., '2026/03/01') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states what data is returned, with no mention of side effects, read-only nature, authentication, rate limits, or error cases. This is insufficient for a safe read operation.
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 a single, front-loaded sentence with no filler. It efficiently conveys purpose and returned data, earning its place without 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?
The tool has 2 required parameters with full schema coverage but no output schema. The description omits the date range (only start_date required), does not clarify if data is for a single day or range, and lacks pagination or limits. For a simple tool, this is incomplete.
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 input schema covers 100% of parameters with clear examples and format hints. The tool description adds no additional parameter context beyond schema, so a 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 tool retrieves daily wholesale market trade data for an agricultural product, specifying the resource and verb. It distinguishes from siblings by focusing on 'daily' data and lists returned fields (volume, prices). This is specific and unambiguous.
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 daily granularity but does not explicitly state when to use this tool over siblings like get_weekly_trades or get_monthly_trades. No alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent transaction history across all Taiwan wholesale markets for a product. Returns per-market volume and price time series data.
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Product item code (e.g., 'LA1' for lettuce) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It states 'Get recent transaction history' without clarifying what 'recent' means (time range), whether the operation is read-only, or any permissions needed. The lack of detail on safety and side effects is a gap.
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 two sentences, front-loading the purpose and return type. It is efficient with no wasted words. Could potentially add more detail without being 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?
For a tool with one parameter and no output schema, the description explains what is returned (volume and price time series by market) but omits specifics like time window for 'recent', number of records, or pagination. This is adequate but not fully 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?
The input schema covers 100% of parameters with a description for item_code. The tool description does not add meaning beyond the schema (e.g., no additional context on how to find item codes). 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 specifies the verb 'Get', the resource 'recent transaction history across all Taiwan wholesale markets for a product', and the return format 'per-market volume and price time series data'. This differentiates the tool from siblings like get_daily_trades which likely aggregate by time period.
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 cross-market transaction history but does not explicitly state when to use this tool over siblings like get_daily_trades or search_products. No exclusions or alternatives are mentioned, leaving the agent to infer context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get monthly wholesale market trade summaries for an agricultural product. Returns transaction volume (kg) and average price (TWD/kg) per month.
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Product item code (e.g., 'LA1' for lettuce) | |
| start_date | Yes | Start date in YYYY/MM/DD format (e.g., '2025/01/01') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool returns summaries in a read-only manner, but does not disclose authentication needs, rate limits, or data scope limitations. It is minimally adequate but lacks depth.
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?
Two sentences front-loaded with purpose and return value. No extraneous words. 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 output schema, the description explains return values adequately. Parameters are covered. Missing aspects like date range logic or subsetting are not critical for a monthly summary tool, so it is mostly 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 100% with clear parameter descriptions (item_code and start_date with examples). The description does not add extra meaning 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 verb 'Get', the resource 'monthly wholesale market trade summaries', and specifies the return fields (transaction volume in kg and average price in TWD/kg). It distinguishes from siblings by emphasizing the monthly aggregation.
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 does not explicitly indicate when to use this tool over its siblings (e.g., get_daily_trades, get_weekly_trades) or provide when-not-to-use guidance. Usage is only implied by the monthly nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weekly wholesale market trade summaries for an agricultural product. Returns transaction volume (kg), average price (TWD/kg), and total value per week.
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Product item code (e.g., 'LA1' for lettuce) | |
| start_date | Yes | Start date in YYYY/MM/DD format (e.g., '2026/01/01') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the return values but omits details on rate limits, permissions, or whether the operation is read-only. The behavior is implied but not fully transparent.
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 a single sentence that efficiently conveys purpose and output. It is concise, though could be slightly more structured by separating function and results. No redundant 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?
The description explains what the tool returns and for what product, but lacks clarity on the exact date range (e.g., week starting from start_date, inclusive?) and does not link to sibling tools. Adequate but incomplete for a clear 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 description coverage is 100% with clear parameter descriptions. The tool description adds context about weekly summaries but does not provide additional semantic meaning beyond the schema. 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 'Get', the resource 'weekly wholesale market trade summaries for an agricultural product', and specifies the returned fields (volume, price, total value). This distinguishes it from siblings by granularity.
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 weekly data but does not explicitly state when to use this tool vs alternatives like get_daily_trades or get_monthly_trades. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get yearly wholesale market trade summaries for an agricultural product. Historical data available back to 1996.
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Product item code (e.g., 'LA1' for lettuce) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It notes historical data back to 1996 but fails to disclose whether the operation is read-only, any side effects, data security, or what the summaries contain (e.g., total volume, price). This is insufficient for a read tool without 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?
The description is two concise sentences with no fluff, front-loaded with the core purpose. It is appropriately sized for a simple tool.
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 output schema, the description should clarify return structure, but it only vaguely mentions 'summaries'. For a tool with one parameter, it is adequate but could improve by describing fields (e.g., 'total trade volume, average price'). Sibling differentiation is also limited.
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 a single parameter (item_code) described in the schema. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 ('Get'), the resource ('yearly wholesale market trade summaries'), and the domain ('agricultural product'). It distinguishes from sibling tools like get_daily_trades by specifying yearly granularity.
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 yearly historical summaries (since 1996) but does not explicitly guide when to use this tool over alternatives like get_monthly_trades or get_weekly_trades. No explicit exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Taiwan agricultural products by name or item code. Returns matching products with their item codes for use in other trade data tools.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword for product name or code (e.g., '高麗菜', 'LA1', '椰子') |
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 that the tool returns matching products with item codes, implying a list output. However, it does not detail behavior for no matches, pagination, or search precision, leaving some gaps for a search tool.
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?
Two sentences, no extraneous information. The first sentence states the action and scope, and the second explains the purpose. Front-loaded and efficient.
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 low complexity (1 param, no output schema), the description adequately covers the tool's purpose and output. However, it omits details like partial matching or handling multiple results, which would enhance completeness for a search 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 100% for the single 'keyword' parameter, which already includes examples. The tool description adds context about the output but does not significantly enhance parameter semantics beyond what the schema provides. 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 function: 'Search Taiwan agricultural products by name or item code' and specifies it returns item codes for use in other tools. It is a specific verb+resource and distinguishes from sibling trade data retrieval tools.
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 as a preparatory step for other tools ('for use in other trade data tools'), but does not explicitly state when to use versus alternatives. Sibling tools are all data retrieval, so context is clear, but explicit guidance is missing.
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.0get_daily_tradesget_market_historyget_monthly_tradesget_weekly_tradesget_yearly_tradessearch_productsMost tools have distinct temporal granularities (daily/weekly/monthly/yearly) and search_products is clearly different. However, get_daily_trades and get_market_history overlap in describing daily wholesale data, which could cause confusion.
Consistent verb_noun snake_case pattern, but 'search_products' uses 'search_' instead of 'get_', which is a minor inconsistency.
Six tools cover the core functionality of retrieving trade data at different time periods plus product search, well-scoped for a data retrieval server.
Covers key query dimensions (product search, various temporal aggregations, market history). Missing features like geographic filtering or cross-market comparisons, but the core lifecycle is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Taiwan Stock Exchange (TWSE) open data as MCP tools: stock quotes, ETF data, 140+ public datasets.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Cleaned Taiwan 實價登錄: real-area (去公設) per-ping prices, de-parking. 7 MCP tools.
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asgard-ai-platform/mcp-twfood'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
