MCP TDCC

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear distinct purposes (director holdings, e-voting, NAV, etc.), though get_stock_monthly_changes and get_stock_weekly_balance both track custody changes at different timeframes, creating slight overlap. The generic get_tdcc_opendata tool could also cause selection ambiguity but its description clarifies it as a fallback for any endpoint.
Naming Consistency5/5
All tool names consistently start with 'get_' followed by descriptive nouns with underscores (e.g., get_director_shareholding, get_securities_info). No mixing of conventions or vague verbs.
Tool Count5/5
8 specialized tools plus one generic endpoint cover the major TDCC data categories (securities, holdings, custody, offshore funds, e-voting) without being too few or too many. The scope is well-calibrated for a financial data server.
Completeness4/5
Core data like securities info, share distribution, custody changes, and e-voting are covered directly. Some areas (e.g., offshore fund basic info) are missing specialized tools, but the generic get_tdcc_opendata tool allows access to all 100+ endpoints, filling potential gaps.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 mentions the output fields (balance, change, ratio) but does not disclose any behavioral traits like data freshness, rate limits, or authentication needs. For a read-only query tool, it is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose. It is concise and avoids redundancy. Nearly every sentence adds value, though the second sentence could be merged or omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description lacks completeness. It does not explain return format, date coverage, or any limitations. For a query tool, users need to know what dates are available or how the balance is calculated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The description adds no extra meaning beyond the schema, e.g., it does not clarify the date range or provide examples. Baseline of 3 is appropriate as the schema handles parameter documentation.
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 it queries TDCC weekly custody balance for a stock, specifying the data shown (weekly balance, change, issuance ratio). It distinguishes from siblings like get_director_shareholding or get_securities_info by focusing on a specific custody metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Useful for short-term custody movement tracking' which provides a use case but does not explicitly state when to use vs alternatives or when not to use. Sibling tools are listed but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose behavioral traits such as read-only nature, rate limits, pagination, or error handling. Only 'Query' suggests non-mutating, but more details are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by examples and a structured category list. Some redundancy in examples, but overall efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover return format, pagination, and authentication. It fails to do so, leaving the agent with insufficient context for a tool that queries 100+ endpoints.
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 coverage is 100%, and the description adds value by mapping endpoint_id categories (e.g., 1-x: Share administration). This helps the agent understand endpoint patterns beyond the schema examples.
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 the verb 'Query' and the resource 'any TDCC OpenData endpoint by ID'. It provides numerous examples and a category breakdown, distinguishing it from the sibling tools which are specific endpoints.
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 implies usage for any TDCC endpoint not covered by specific sibling tools, but does not explicitly state when to use this over alternatives. The category listing aids in selecting appropriate endpoint IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates read-only behavior ('Shows') but lacks details on rate limits, authentication, error handling, or data freshness. Sufficient for a simple query tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states purpose, second lists output fields. Front-loaded and efficient.
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?
Given no output schema, the description adequately summarizes return fields. Tool is simple with one parameter, and description covers the essential output. Could mention error cases or data range but not critically missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'stock_code' described as 'Securities code, e.g. 2330.' Description adds no further semantic detail beyond the schema. Baseline score of 3 is appropriate since schema already handles the parameter documentation.
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?
Description clearly states the tool queries TDCC director/supervisor custody data with specific verb 'Query' and resource. It lists exact data items (custody shares, mandatory custody total shares, issued shares). Sibling tools address different data domains (voting, fund NAV, securities info, etc.), so this tool is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for querying director/supervisor shareholding by stock code but does not provide explicit when-to-use or when-not-to-use guidance. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description discloses that it queries and shows information, but does not explicitly state it is read-only, or discuss authentication, rate limits, or other behavioral traits.
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?
Two concise sentences: first defines purpose, second gives a usage example. No redundant information.
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 explains what the tool returns (meetings, dates, voting periods) and a special case (statistics). No output schema exists, so a bit more detail on output structure would improve completeness, but it's adequate for a simple query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds minimal extra meaning (e.g., 'statistics' for ratios), but mostly the schema already covers parameter semantics.
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 it queries TDCC shareholder e-voting information, including upcoming meetings, dates, and voting periods. It distinguishes well from siblings (e.g., director shareholding, fund NAV) by focusing on e-voting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using 'statistics' for participation ratios, giving some usage context. However, it does not explicitly state when to use this tool vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It describes the output (number of shareholders and shares at each tier) but does not disclose whether the operation is read-only, any required permissions, rate limits, or side effects. For a data retrieval tool, the read-only nature is implied but not stated.
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?
Three sentences with no waste: first states the core function, second describes output, third gives a use case. Information is front-loaded and every sentence earns its place.
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?
For a simple single-parameter tool with no output schema, the description adequately covers purpose, output, and usage context. Missing details like data source or update frequency are minor but do not severely hinder usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'stock_code' is already documented with an example. The description adds the context 'for a given stock' and 'by tier' but does not provide additional semantic detail beyond what the schema offers. Baseline 3 is appropriate.
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 the tool queries TDCC shareholding distribution by tier, showing number of shareholders and shares per tier for a given stock. The verb 'Query' and resource 'shareholding distribution' are specific. Sibling tools like get_director_shareholding and get_evoting_info handle different data, so this tool is well-distinguished.
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 says it is 'Essential for analyzing retail vs institutional ownership structure,' providing a clear usage context. It does not list alternatives or when-not-to-use, but the context is sufficiently clear given the distinct sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden. It lists the output fields (custody shares, changes, percentage, etc.) but does not disclose any behavioral traits such as data freshness, rate limits, or whether it is safe (read-only). The lack of annotations makes this a minimal disclosure.
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 with just three sentences, front-loading the key purpose and listing output fields in the second sentence. Every sentence adds value without redundancy.
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 lists the major output fields (custody shares, changes, percentage, issued shares, number of shareholders), which compensates for the lack of an output schema. However, it does not mention date range, frequency (monthly is implied), or any limitations, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema's type, example, and default. Baseline score of 3 is appropriate as the schema already provides adequate documentation for both parameters.
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 uses the verb 'Query' with the specific resource 'TDCC monthly custody change analysis for a stock', immediately identifying the tool's purpose. It also distinguishes this from siblings like 'get_stock_weekly_balance' by emphasizing the monthly frequency and the specific analysis table.
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 states 'Useful for tracking custody trends', which implies when to use it. However, it does not explicitly contrast with siblings like 'get_shareholding_distribution', leaving room for ambiguity. The guidance is clear but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the behavioral burden. It discloses that the tool returns the latest NAV, supports partial match filtering, and returns a limited result set (first 50). This is sufficient for a read-only query tool.
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?
Three concise sentences: purpose with context, return value description, and usage guidance. No filler or redundancy. Information is front-loaded and easy to scan.
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 simple query tool with two optional parameters and no output schema, the description covers everything needed: what it returns (latest NAV), how to filter, default behavior (first 50). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (fund_code, fund_name) have descriptions noting partial match support. The description adds no new details beyond restating that these parameters are for filtering, so it meets the baseline without additional value.
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 uses a specific verb 'Query' and precisely identifies the resource 'TDCC offshore fund net asset values'. It clearly distinguishes from sibling tools like get_director_shareholding or get_securities_info, which cover entirely different data domains.
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 states that fund_code or fund_name can be used for filtering and mentions a default limit of 50 results when no filter is given. While it lacks explicit 'when to use vs. alternatives' guidance, the tool's unique purpose among siblings makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly portrays a read-only query, specifies return fields, and mentions a 50-result limit. No contradictions, but lacks details on pagination, authorization, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the purpose and efficiently cover return data and filtering. No extraneous information.
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?
Given only 3 optional parameters and no output schema, the description is largely complete. It lists return fields and limits. Could enhance by noting pagination behavior for result sets beyond 50, but adequate for typical use.
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?
Schema covers 100% of parameters with descriptions, and the description adds value by noting partial match support for stock_code and stock_name and listing market filter values. Exceeds baseline expectations.
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?
Clearly states it queries TDCC securities basic information, lists returned fields (code, name, market type, etc.), and specifies filtering options. Distinguishes from siblings like get_director_shareholding or get_evoting_info which cover different data.
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 says to use stock_code or stock_name for filtering, and that no filter returns all results up to 50. Implies this is for basic securities info compared to sibling tools, but no explicit when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-tdcc MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-tdcc/badges/card.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-tdcc)

Score Badge

Copy to your README.md:

[![mcp-tdcc MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-tdcc/badges/score.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-tdcc)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/asgard-ai-platform/mcp-tdcc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server