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., "@thailand-data-mcp Look up company juristic ID 0107536000315"
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 exposing Thailand data tools for AI agents: official company-registry lookups, Thai address normalization, public holidays, and VAT/withholding-tax reference.
Tool | What it does |
| Official DBD registry profile by 13-digit juristic ID: TH/EN name, type, status, registration date, registered/paid-up capital, business objective, registered address. Live data, cached 24h. |
| Free-text Thai address (TH/EN) → structured province/district/subdistrict/postcode with official codes, confidence level, ambiguity candidates, and street-part extraction. Fully offline. |
| Canonical list of all 77 provinces, bilingual, with codes. |
| Thai public holidays (2025–2026) with lunar-holiday flags. |
| VAT rate/threshold/filing + common WHT rates and the 50 ทวิ certificate rule. Reference only, not tax advice. |
Related MCP server: eu-company-mcp-server
pnpm install
pnpm build
node dist/index.js # stdio (default)
TRANSPORT=http PORT=3000 node dist/index.js # streamable HTTP at /mcp (binds 127.0.0.1)Claude Code registration:
claude mcp add thailand-data -- node /path/to/thailand-data-mcp/dist/index.jsNo API keys required.
thai_company_lookup {"juristic_id": "0107536000315"}
→ KASIKORNBANK PUBLIC COMPANY LIMITED | บริษัทมหาชนจำกัด | ยังดำเนินกิจการอยู่ | capital 30,246,820,970 THB | ...
thai_address_normalize {"address": "เลขที่ 5 ซอยสุขุมวิท 39 แขวงคลองตันเหนือ เขตวัฒนา กรุงเทพฯ"}
→ province กรุงเทพมหานคร / district วัฒนา / subdistrict คลองตันเหนือ / 10110 | confidence: high | street: "เลขที่ 5 ซอยสุขุมวิท 39"Company registry: DBD Open Data openapi.dbd.go.th — used under the DGA Open Government License, which requires source attribution; every response therefore carries an attribution field. Do not strip it.
Geography: thailand-geography-data/thailand-geography-json (MIT) — bundled in data/.
Holidays / VAT: bundled reference data; verify critical values against official announcements (Royal Gazette, Revenue Department, Bank of Thailand).
DBD lookups are cached in-memory for 24h (registry data changes slowly; also keeps request rates polite toward the WAF-fronted upstream).
The DBD API mislabels JSON responses as text/html; the client parses bodies regardless.
HTTP 403/429 from upstream = WAF/rate-limit → the tool returns a retry-later error, not a fabricated "not found".
"Not found" is only reported on the registry's explicit 1004 No data available status.
pnpm dev # tsx watchStack: TypeScript, @modelcontextprotocol/sdk, Zod. No runtime dependencies beyond the SDK.
Parse free-text Thai addresses (Thai or English) into the official administrative hierarchy: province (จังหวัด) → district (อำเภอ/เขต) → subdistrict (ตำบล/แขวง) → postal code, with bilingual names and official codes.
Handles common written forms: abbreviations (ต./อ./จ., กทม.), Bangkok's แขวง/เขต terminology, missing components, and postcode-only inputs. Matching is dictionary-based against the complete official geography (77 provinces, 928 districts, 7,436 subdistricts).
Args:
address (string): free-text address, 2-500 chars
Returns structured JSON: { "province": { "code": number, "nameTh": string, "nameEn": string } | null, "district": { ... } | null, "subdistrict": { ... } | null, "postalCode": number | null, "confidence": "high" | "medium" | "low" | "ambiguous" | "none", "streetHint": string | null, // residual text after removing administrative parts (house no., road, soi) "warnings": string[], // e.g. postcode/subdistrict mismatch "candidates": [...] // present when confidence = "ambiguous"; add district/postcode and retry }
Examples:
Use when: filling a shipping form from a customer's pasted address
Use when: validating that district/province/postcode in a record are consistent
Use when: deduplicating customer records with differently-written addresses
Don't use when: you need geocoding to lat/long (not provided)
Error handling: confidence "none" means nothing matched — the text may not be a Thai address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Free-text Thai address in Thai or English, e.g. '400/22 ถ.พหลโยธิน แขวงสามเสนใน เขตพญาไท กทม 10400'. Partial addresses work — more components give higher confidence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. The description adds rich behavioral detail: dictionary-based matching, scale (77 provinces, 928 districts, 7,436 subdistricts), confidence levels, warnings, and candidate handling for ambiguous matches.
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?
Well-structured with clear sections (purpose, handling, args, returns, examples, error handling). Slightly verbose but every sentence is informative, no fluff.
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?
Completely covers input, output, error states, and usage scenarios. Although no output schema is provided, the description fully specifies the return structure, including nested objects and edge cases like confidence levels.
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 detailed description. The description enhances understanding by showing example formats and explaining partial address handling, adding value beyond the schema.
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 parses free-text Thai addresses into an official administrative hierarchy with bilingual names and codes. It distinguishes itself from sibling tools (company lookup, holidays, etc.) as a unique address normalization function.
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 use cases (filling shipping forms, validating consistency, deduplication) and a clear don't-use condition for geocoding, guiding the agent precisely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Thai company (juristic person) in the official DBD (Department of Business Development) registry by its 13-digit registration number.
Returns the official registry profile: Thai/English name, entity type, operating status, registration date, registered and paid-up capital (THB), business objective (bilingual, with TSIC-style code), and registered head-office address.
Args:
juristic_id (string): exactly 13 digits, e.g. "0107536000315"
Returns structured JSON: { "found": boolean, "company": { "juristicId": string, "nameTh": string, "nameEn": string, "type": string, // e.g. "บริษัทจำกัด" (Co., Ltd.), "บริษัทมหาชนจำกัด" (PCL) "status": string, // e.g. "ยังดำเนินกิจการอยู่" = still operating "registerDate": string, // YYYYMMDD "registeredCapitalBaht": number, "paidUpCapitalBaht": number, "objective": { "code": string, "textTh": string, "textEn": string }, "address": { ... } } | null, "fromCache": boolean, "attribution": string }
Examples:
Use when: verifying a Thai supplier/counterparty exists and is still operating (KYB / due diligence)
Use when: fetching official registered capital or address for a contract
Don't use when: you only have a company NAME — this tool requires the 13-digit ID (ask the counterparty or check their invoice/website footer)
Notes:
"found": false means the ID is not in the registry — it may be mistyped, or the entity may be a sole proprietor (not a juristic person).
Data is the live official registry, cached for 24h.
| Name | Required | Description | Default |
|---|---|---|---|
| juristic_id | Yes | 13-digit Thai juristic person registration number, e.g. '0107536000315'. Printed on invoices, contracts, and company documents; same number as the company's tax ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds caching duration (24h), interpretation of 'found': false (sole proprietor or bad ID), and live source. No contradictions.
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?
Well-structured with purpose, args, returns, examples, notes. Every sentence adds value. Front-loaded with primary verb and resource.
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?
Single parameter fully documented, full sample output provided despite no output schema. Covers all needed context for agent invocation.
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 covers parameter fully (pattern, example, source). Description adds context on where to find the ID (invoices, contracts) and reinforces the format. Just shy of 5 because schema already does most of the work.
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 'Look up a Thai company in official DBD registry by its 13-digit registration number.' Differentiates from siblings which are unrelated (address, holidays, provinces, VAT).
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 provides use cases (KYB, due diligence, contract info) and a key don't-use-when (company name only, requiring 13-digit ID instead). Gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Thai public holidays for a given year (2025, 2026), with dates, Thai/English names, and a flag for lunar-calendar holidays.
Args:
year (number): one of 2025, 2026
Returns structured JSON: { "year": number, "count": number, "holidays": [{ "date": "YYYY-MM-DD", "nameEn": string, "nameTh": string, "lunar": boolean }], "disclaimer": string }
Use when scheduling anything in Thailand: payment due dates, meeting planning, delivery estimates, contract deadlines. Lunar holidays (lunar: true) are fixed by annual announcement — verify for critical deadlines. Bank holidays can differ slightly from public holidays (Bank of Thailand publishes its own list).
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year. Available: 2025, 2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds behavioral context: it returns a disclaimer, mentions lunar holidays are fixed by annual announcement, and advises verification for critical deadlines, which is valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, args, returns, and usage notes. It is front-loaded and every sentence adds value. It could be slightly more concise in the returns section, but overall it's effective and not 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?
Given the tool's simplicity (one parameter, no output schema), the description is thorough. It explains the output format with all fields, includes a disclaimer, and provides usage guidance and caveats. This fully compensates for the lack of 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?
The input schema has 100% description coverage, so the parameter is already documented. The description restates 'one of 2025, 2026' but adds no new semantic detail beyond the schema. A baseline score of 3 is appropriate since the description doesn't compensate further.
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 'List Thai public holidays for a given year (2025, 2026), with dates, Thai/English names, and a flag for lunar-calendar holidays.' This provides a specific verb and resource, and distinguishes from sibling tools like thai_address_normalize or thai_company_lookup which serve different purposes.
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 suggests use cases: 'Use when scheduling anything in Thailand: payment due dates, meeting planning, delivery estimates, contract deadlines.' It also notes caveats about lunar holidays and bank holidays. While it doesn't list alternatives, the sibling tools are unrelated, so no explicit 'when not to use' is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 77 Thai provinces with official codes and bilingual names.
Returns structured JSON: { "count": 77, "provinces": [{ "code": number, "nameTh": string, "nameEn": string }] }
Use when you need the canonical province list for validation, dropdowns, or mapping Thai/English province spellings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true) and idempotent (idempotentHint=true). The description adds return structure, complementing annotations without contradiction.
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?
Three focused sentences: purpose, return structure, usage guidance. No unnecessary words.
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 zero parameters and a simple static data retrieval, the description fully explains what the tool does and returns. Annotations cover safety. No gaps.
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?
No parameters present, baseline is 4. Description adds value by detailing the return format (count and array of objects with code, nameTh, nameEn).
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 action (list), resource (all 77 Thai provinces), and specific details (official codes and bilingual names). It distinguishes from sibling tools like thai_address_normalize and thai_company_lookup.
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 guidance on use cases: validation, dropdowns, mapping. While it doesn't state when not to use, the sibling tools are clearly different, minimizing confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference card for Thai VAT and withholding tax (WHT) basics: standard VAT rate, registration threshold, filing forms and deadlines, and common WHT rates by payment category (services, rent, advertising, transport, dividends, etc.).
No arguments.
Returns structured JSON with "vat", "withholdingTax" (rates table + certificate requirement), and "disclaimers".
Use when: computing invoice amounts involving Thai WHT deduction, checking whether a business must register for VAT, or explaining the 50 ทวิ withholding certificate. Reference only — NOT tax advice; verify with the Revenue Department for filings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: no arguments, returns structured JSON with specific fields (vat, withholdingTax, disclaimers), and is safe to call. No contradictions.
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 with three front-loaded paragraphs: purpose, behavior, and usage guidelines. Every sentence adds value, no redundancy.
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 zero parameters and no output schema, the description fully covers what the tool returns (structured JSON with vat, withholdingTax, disclaimers) and its limitations. No gaps remain.
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?
No parameters exist, and the description explicitly states 'No arguments.' The input schema is empty with 100% coverage, so the description adds the necessary clarity for a parameterless tool.
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 provides a reference card for Thai VAT and withholding tax basics. It identifies the specific resource and action, and its purpose is distinct from sibling tools like thai_address_normalize or thai_company_lookup.
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 states when to use: computing invoice amounts, checking VAT registration, or explaining withholding certificates. Also provides a clear exclusion: 'not tax advice' and advises verification with the Revenue Department. This fully guides agent selection.
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.0thai_address_normalizethai_company_lookupthai_holidaysthai_list_provincesthai_vat_referenceEach tool targets a unique domain: address parsing, company lookup, holidays, province list, and VAT reference. No two tools overlap in purpose, making selection unambiguous for an agent.
All tool names follow the snake_case pattern 'thai_<verb>_<noun>', starting with 'thai_' and using consistent verb conventions (normalize, lookup, list, reference). No mixed styles or cryptic names.
With 5 tools, the server is well-scoped for Thailand-specific data queries. Each tool covers a distinct need without being too few for practical use or too many to navigate.
The tool set covers major data needs: addresses, companies, holidays, provinces, and tax info. Minor gaps exist, like geocoding or individual district lists, but these are not essential for the core purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/narinthon-so/thailand-data-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server