A
licenseB
qualityB
maintenanceSelf-hostable, read-only Taiwan stock-analysis MCP server that retrieves market data and computes reproducible indicators.
6
15
21
MIT
tw-market-data
Ownership verified
Server Details
Taiwan stock market data (TWMD): official-source, point-in-time-safe datasets via read-only tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.5/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: list_datasets for discovery, describe_dataset for schema and semantics, query_dataset for data retrieval, and find_related for relationships. There is no overlap or ambiguity among them.
Naming Consistency5/5
All tool names follow a consistent lowercase_with_underscore verb-noun pattern (list_datasets, describe_dataset, query_dataset, find_related). The style is uniform and predictable.
Tool Count5/5
With 4 tools, the server is well-scoped for a Taiwan market data domain. Each tool earns its place, covering discovery, understanding, extraction, and relationship traversal without redundancy.
Completeness5/5
The tool surface covers the full lifecycle of working with a data API: list datasets, get detailed metadata, query data with point-in-time safeguards, and explore relationships across datasets and tickers. No obvious gaps exist for the stated purpose.
Available Tools
4 toolsdescribe_datasetARead-onlyIdempotentInspect
FULL semantics of one dataset: grain (what a row is), field meanings+units, ★TIME-CORRECTNESS rules (knowledge_time_field / point_in_time_safe — read before backtesting), relations for cross-table reasoning, agent_hints (when to use), quant_use (which factors). Args: dataset_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| hint | No | |
| tier | No | |
| error | No | |
| grain | No | |
| name_zh | No | |
| category | No | |
| coverage | No | |
| temporal | No | |
| quant_use | No | |
| relations | No | |
| key_fields | No | |
| adjustments | No | |
| agent_hints | No |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior. The description adds valuable context about time-correctness rules (knowledge_time_field / point_in_time_safe) and warns that this must be read before backtesting, which is critical behavioral information not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single information-dense sentence with clear structure (colon-separated list of output components). It front-loads the core purpose and includes no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, key output content, and a critical usage warning. The presence of an output schema reduces the need to detail return values. However, it could have mentioned obtaining dataset_id from list_datasets, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for dataset_id, and the description only repeats 'Args: dataset_id' without explaining its origin or format. This fails to compensate for the 0% schema coverage, leaving the agent to infer that dataset_id is a dataset identifier, likely from list_datasets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool provides the full semantics of a dataset, enumerating specific components such as grain, field meanings, time-correctness rules, relations, and usage hints. This distinguishes it from sibling tools like query_dataset (returns data) and list_datasets (lists datasets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to 'read before backtesting,' establishing a clear when-to-use guideline. It also mentions 'agent_hints (when to use)' as part of the output, though it doesn't explicitly contrast with alternatives like query_dataset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_datasetsARead-onlyIdempotentInspect
List available Taiwan-market datasets (discovery entry point). Returns id / 中文名 / category / tier / one-line description for each. Use this first to find the right data.
Args:
category: optional, e.g. 'chip'(籌碼) 'fundamental'(基本面) 'price'(行情) 'macro'(總經)
'relation'(關聯/產業鏈) 'derivatives'(期權) 'event'(事件) 'rag_text'(文本).
tier: optional minimum plan: 'free' 'starter' 'pro' 'max' 'developer' 'enterprise'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| category | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| datasets | No |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by specifying the exact return fields (id, 中文名, category, tier, one-line description), which helps set expectations for a listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a one-sentence purpose, a one-sentence return summary, and a compact usage directive. The Arg format is clean and each line adds value. No redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a discovery/list tool with two optional filters and an output schema (present), the description is complete. It covers what to use first, what the output contains, and how to filter. Given the output schema exists, it does not need to detail return structure further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates: it explains the `category` parameter with explicit examples ('chip'(籌碼) 'fundamental'(基本面) etc.) and defines `tier` as 'optional minimum plan' with a list of valid values. This adds meaning beyond the bare string/null schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List available Taiwan-market datasets', clearly identifying it as a discovery entry point. It also differentiates from siblings by stating 'Use this first to find the right data', implying other tools (describe/query) operate on a chosen dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself as the first step: 'Use this first to find the right data'. This gives clear context for when to use, but does not explicitly name alternatives or exclusion cases. Still, the discovery-purpose framing makes usage obvious relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_datasetARead-onlyIdempotentInspect
Query rows with built-in look-ahead protection.
★ POINT-IN-TIME: pass `as_of` (YYYY-MM-DD) for backtesting/agent-learning. For non-point-in-time-safe
datasets (fundamentals, monthly_revenue, dividend_policy…) rows are filtered by DISCLOSURE date <= as_of,
so the agent only sees what was public at that moment. Omit as_of only for present-day lookups (warned).
Args:
dataset_id: see list_datasets. tickers: e.g. ['2330','2317']. start/end: 'YYYY-MM-DD' range.
as_of: knowledge-time cutoff 'YYYY-MM-DD' (use for backtests). limit: <=5000.
Returns: {meta:{table,coverage,row_count,as_of_applied,point_in_time_safe,warnings}, data:[...]}
Example: query_dataset('fundamental_income', tickers=['2330'], as_of='2023-06-30')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| as_of | No | ||
| limit | No | ||
| start | No | ||
| tickers | No | ||
| dataset_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| hint | No | |
| meta | No | |
| error | No | |
| status | No | |
| blocked | No | |
| message | No |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description dives deeper into the point-in-time filtering behavior, including disclosure-date logic for non-PIT-safe datasets and warnings. This adds significant behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with a highlighted point-in-time note, an Args list, a Returns summary, and an example. No filler; all content contributes to understanding usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential aspects for a query tool: parameters, special semantics, return structure, and an example. With annotations and output schema handling safety and return details, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: dataset_id references list_datasets, tickers given example, start/end format, as_of meaning, and limit max value. This satisfies the need for parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query rows with built-in look-ahead protection', naming the resource (rows) and distinguishing it from siblings like list_datasets and describe_dataset. The addition of 'look-ahead protection' clarifies its unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use as_of (backtesting/agent-learning) and when to omit (present-day lookups), but does not explicitly contrast with sibling tools like list_datasets for dataset discovery. Still, the context is strong enough for an agent to infer.
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
Anthonychiu120523 days ago
very good
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides real-time access to Taiwan Stock Exchange market data, financial reports, and trading analytics. It enables users to query stock prices, market indices, and corporate profitability metrics through natural language.22346MIT
- Flicense-qualityBmaintenanceProvides Taiwan stock market data through FinMind v4 API, including daily OHLCV, monthly revenue, institutional investors, margin trading, dividends, and financial statements. Enables MCP clients like ChatGPT or Codex to query Taiwan financial datasets via simple tools.
- AlicenseCqualityDmaintenanceProvides comprehensive Taiwan stock market data and analysis through MCP tools. Enables querying real-time stock prices, historical data, company information, technical analysis, and market overviews for TWSE and TPEx listed companies.815MIT