Click on "Deploy 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., "@creden-mcp ค้นบริษัท ปตท. จำกัด งบการเงิน 5 ปีย้อนหลังและรายชื่อกรรมการ"
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 ที่ให้ AI agent (Claude Code / Claude Desktop) ดึงข้อมูลบริษัทไทยจาก data.creden.co ได้ — ค้นด้วยชื่อภาษาไทย/อังกฤษ หรือเลขนิติบุคคล แล้วได้ profile, งบการเงิน 5–10 ปี, กรรมการ, % ผู้ถือหุ้น, ผู้มีอำนาจลงนาม ในการเรียกเดียว
"<ชื่อบริษัท>"
↓ creden_lookup
↓
บริษัท ABC จำกัด (id=0123456789012)
จดทะเบียน <date> · ทุน <amount> บาท · <industry>
ปี (พ.ศ.) รายได้รวม กำไรสุทธิ สินทรัพย์รวม YoY%
<year> ... ... ... ...
<year> ... ... ... ...
กรรมการ: <list>
ผู้มีอำนาจลงนาม: <list>
ผู้ถือหุ้น: <pct1>% / <pct2>% (ไทย 100%)
ราคาต่อหุ้น: <shares> หุ้น × ...ไม่ต้อง login สำหรับข้อมูลส่วนใหญ่ — profile + งบการเงิน 5–10 ปี ใช้ public HTML route
กรรมการ / ผู้ถือหุ้น % อยู่หลัง free-tier login (ใส่ credentials ใน .env)
Auto re-login ถ้า session หมด ระบบ detect 401 → login ใหม่ → retry อัตโนมัติ
Single tool — call เดียวได้ทุกอย่าง agent ไม่ต้องตัดสินใจระหว่างหลาย tool
ทำงานกับ Claude Code, Claude Desktop, หรือ MCP client อื่นๆ ที่ speak stdio
Related MCP server: Bizfile MCP
git clone https://github.com/<your-username>/creden-mcp.git
cd creden-mcp
python3 -m venv .venv
.venv/bin/pip install -e .ต้องการ Python ≥ 3.11
claude mcp add creden --scope user $(pwd)/.venv/bin/creden-mcp
claude mcp list | grep creden # → ✓ Connectedใน session ใหม่ของ Claude Code ถามได้เลย:
"งบการเงิน 5 ปีของ <ชื่อบริษัท>"
"ใครเป็นกรรมการบริษัท <ชื่อ>"
"ค้นบริษัท <ชื่อ>"
"นิติบุคคลเลข <id 13 หลัก> ทำธุรกิจอะไร"~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"creden": {
"command": "/absolute/path/to/.venv/bin/creden-mcp"
}
}
}cp .env.example .env
# แก้ไข .env ใส่ CREDEN_EMAIL / CREDEN_PASSWORDไม่ใส่ก็ใช้ได้ — แค่ field ที่ gate (กรรมการ/ผู้ถือหุ้น/ผู้ลงนาม) จะเป็น null พร้อม auth_data_status บอกเหตุผล
ใส่แล้ว register แบบ inline ก็ได้ (ไม่ต้องมี .env ในโปรเจกต์):
claude mcp add creden --scope user \
--env CREDEN_EMAIL=you@example.com \
--env CREDEN_PASSWORD=secret \
/path/to/.venv/bin/creden-mcpTool | Purpose |
| Main: ชื่อ หรือ id 13 หลัก → ข้อมูลครบในการเรียกเดียว |
| คืน list candidates สำหรับชื่อที่ ambiguous |
ผลที่ได้จาก creden_lookup (โครงสร้างตัวอย่าง):
{
"company": {
"th": "บริษัท ... จำกัด",
"en": "... CO., LTD.",
"juristic_id": "0123456789012",
"register_date_th": "...",
"register_capital": 1000000,
"industry_th": "<TSIC code> : <description>",
"address_th": "...",
"objective": "..."
},
"fiscal_years": [
{ "FISCAL_YEAR": 2566, "BAL_IN09": 0, "BAL_IN21": 0, "BAL_BS22_BAL_BS99": 0 },
{ "FISCAL_YEAR": 2567, "BAL_IN09": 0, "BAL_IN21": 0, "BAL_BS22_BAL_BS99": 0 }
],
"directors": [{ "name_search": "...", "name_search_en": "...", "index": 1 }],
"director_history": [/* เข้า/ออก กรรมการ พร้อมวันที่ */],
"shareholders_summary": {
"percentages": [50.0, 50.0],
"names_masked": ["A", "B"],
"by_nationality": [{ "nationality": "TH", "pct": 100 }]
},
"authorized_signers": ["..."],
"signing_rule": "...",
"share_info": { "total_shares": 0, "price_per_share": 0 },
"auth_data_status": "fetched"
}creden_lookup(query, full=True) คืน DBD codes ทุก field (~50 fields/ปี)
src/creden_mcp/
config.py env / .env loading (pure dataclass)
page_parser.py parse window.__NUXT__ → dict (regex-based, var-name agnostic)
client.py async httpx client; auto re-login on session expiry
server.py MCPServer — 2 tools wrapping client.lookup
models.py loose Pydantic shapes
discovery.py Playwright XHR capture (สำหรับหา endpoint ใหม่)Public flow (no auth):
suggest /sapi/search/get_suggestion → company_id
GET /company/general/<id> → HTML with full Nuxt-hydrated state
→ parse profile + fiscal yearsAuth flow (.env credentials):
POST /sapi/authen/login → cookie session
POST /sapi/company/get_detail_minor_general → director history,
shareholders %, signers, shares
POST /sapi/company/get_detail_sub_general → current directorsSession expiry → ถ้า 401 หรือ body มี "session expired" → auto re-login → retry ครั้งเดียว
ไม่มี (และไม่สามารถดึงได้ด้วย free Creden tier):
ชื่อผู้ถือหุ้นเต็ม — masked เป็น "A", "B", … เห็นแค่ % และสัญชาติ
ผู้สอบบัญชี (ชื่อจริง) — masked
Email/phone บริษัท — masked
fs_score / credit term / value per share precise — masked, paid tier
บริษัทมหาชน + ข้อมูล realtime — สำหรับ listed companies (มหาชน) ใช้ SET/SEC สำหรับข้อมูลผู้ถือหุ้นเต็มและงบไตรมาสล่าสุด
pip install -e ".[dev]"
pytestโครงการนี้เรียก data.creden.co API + scrape Nuxt-hydrated HTML. ผู้ใช้ต้องรับผิดชอบในการปฏิบัติตาม Terms of Service ของ Creden
Credentials ของคุณส่งตรงไปที่ Creden — โครงการนี้ไม่ proxy ผ่าน server กลาง
Default request delay = 1.5 วินาที (ปรับใน .env ได้) — ปรับลงด้วยความระมัดระวังเพื่อไม่กระทบ Creden quota
เครื่องมือนี้ใช้สำหรับการเข้าถึงข้อมูลที่ผู้ใช้มีสิทธิ์เข้าถึงอยู่แล้วผ่าน Creden อย่าใช้เพื่อรวบรวมข้อมูลส่วนบุคคลของบุคคลที่สามโดยไม่ได้รับอนุญาต
MIT © 2026 phpgng
Look up a Thai company's profile, financial statements (งบการเงิน), and directors (กรรมการ) from data.creden.co (DBD-sourced). Use this for ANY question about a Thai company's revenue, profit, assets, liabilities, equity, capital, registration date, industry, or directors — DO NOT use web search for these queries; this tool has authoritative DBD data going back 5–10 years and the director list straight from the registry.
ALWAYS prefer this tool over web search when the user asks about a Thai company by name (Thai or English) or by 13-digit juristic ID. Examples:
• "ค้น <ชื่อบริษัท>", "งบบริษัท <ชื่อ>", "ข้อมูล <ชื่อ>" • "กรรมการของ <ชื่อ>", "ใครเป็นกรรมการ <ชื่อ>" • "บริษัท <ชื่อ> กำไรเท่าไหร่ปี 2567" • "นิติบุคคลเลข 0123456789012" (13 digits) • " revenue / directors / financials"
Args: query: Thai or English company name, partial name, or 13-digit Thai juristic ID. lang: 'th' (default) or 'en'. full: False (default) returns headline metrics. True returns all ~50 DBD fields per fiscal year.
Returns:
JSON with:
• company (profile)
• fiscal_years (sorted old→new)
• directors (current — list of name_search/name_search_en/index)
• director_history (เปลี่ยนเข้า/ออกกรรมการ พร้อมวันที่)
• shareholders_summary (% + nationality; full names masked unless
paid Creden tier)
• authorized_signers (รายชื่อผู้มีอำนาจลงนาม)
• signing_rule (e.g. "กรรมการหนึ่งคนลงลายมือชื่อ...")
• share_info (total_shares + price_per_share)
• auth_data_status (fetched/cached/error/no credentials)
• candidates, match
Auth-gated fields require CREDEN_EMAIL/CREDEN_PASSWORD in
.env; without them, financials/profile still work fine. Auth data
cached on disk for 30 days to avoid burning Creden points.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| lang | No | th | |
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so: auth-gated fields need CREDEN_EMAIL/CREDEN_PASSWORD, unauthenticated calls still return financials/profile, shareholder names are masked unless on a paid tier, auth data is cached 30 days to avoid burning Creden credits, and auth_data_status reports fetched/cached/error/no-credentials.
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?
Purpose and the web-search exclusion are front-loaded where they matter most, and the Args/Returns blocks are scannable. The Returns list partially duplicates the existing output schema and the example list is long, but no sentence is misleading.
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?
Covers everything an agent needs: what is returned, how ambiguous names resolve (candidates, match), ordering of fiscal_years, that director_history carries join/exit dates, and the credential/caching behavior. The output schema exists, so the extra return detail is orientation rather than a required substitute.
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 0%, so the description must compensate, and it documents all three parameters: query accepts Thai or English names, partial names, or a 13-digit juristic ID; lang is 'th' (default) or 'en'; full False returns headline metrics while True returns ~50 DBD fields per fiscal year.
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?
States a specific verb and resource set (company profile, financial statements, directors) and names the authoritative source (data.creden.co, DBD-sourced). It clearly separates itself from web search, but never mentions the actual sibling creden_search, so an agent must guess whether a partial-name query belongs here or there.
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?
Strong when-to-use coverage: 'ANY question about a Thai company's revenue, profit, assets... directors', explicit exclusion ('DO NOT use web search'), a preference rule, and five concrete query examples in Thai and English. The only gap is that it gives no guidance relative to creden_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Thai companies by name and return all candidates (autocomplete).
Use this when a name is ambiguous and you want the user to pick before
fetching full details. Each result has {id, name_th, name_en}; pass the
chosen id to creden_lookup.
Prefer this over web search for resolving Thai company names. Examples:
• "มีบริษัทชื่อ XYZ กี่แห่ง" → use this to enumerate • "ค้นบริษัทที่ขึ้นต้นด้วย 'ทรู'" → use this for autocomplete
Args: text: Partial or full company name (Thai or English). lang: 'th' (default) or 'en'.
Returns: JSON: {query, count, results: [{id, name_th, name_en}, ...]}.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | th | |
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does most of it: it reveals the non-destructive enumeration behavior, the exact result element shape, and the follow-up handoff. It never states result caps, pagination, or whether an empty/ambiguous query errors out, which matters for a search that is meant to enumerate 'all candidates'.
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?
Purpose and the when-to-use rule are front-loaded, and the examples are short and illustrative. The 'Args' and 'Returns' blocks partially restate the input schema and the existing output schema, which is redundant given structured fields already carry that.
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?
An output schema exists, so return values need not be explained, yet the description still names the fields. For a two-parameter read-only search the definition is nearly self-sufficient; only edge-case behavior (no matches, result limits, ambiguous lang) is unaddressed.
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 0%, so the description must compensate and does: 'text' is documented as partial or full name in Thai or English, and 'lang' is given the actual enum values 'th'/'en' with the default — information the schema omits since it declares no enums. Every parameter is covered with semantics beyond its name.
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?
States a specific verb and resource ('Search Thai companies by name') plus the scope of results ('return all candidates (autocomplete)'). It explicitly names the sibling creden_lookup and explains the division of labor, so the agent can distinguish the two without opening either schema.
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?
Gives an explicit use condition ('when a name is ambiguous and you want the user to pick before fetching full details'), a follow-up action (pass the chosen id to creden_lookup), and a routing rule ('prefer this over web search'). The two Thai-language examples further pin down the invoke-vs-not decision.
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.
v0.1.0creden_lookupcreden_searchScored across 2 tools
creden_search resolves ambiguous names into candidates, while creden_lookup fetches full company detail by name or 13-digit ID. The boundary is explicitly documented (search → pick id → lookup), though the two tools do overlap when a lookup is given a name instead of an ID.
Both tools follow the same creden_<verb> snake_case pattern (creden_lookup, creden_search). No mixed conventions or stray prefixes.
Two tools is thin even for a narrow read-only domain; a search+fetch pair covers the core flow but there is little room for argument. It is not a mismatch, just borderline.
Search plus a very rich lookup (profile, multi-year financials, directors, history, shareholders, signers) covers the stated purpose well. Remaining gaps (e.g. no bulk/list enumeration or tier/auth management surface) are minor and mostly handled by the lookup's own flags.
Company profile lookup and B2B company search for AI agents.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Data for your AI agent: company, people, SEO, social and EU registry data. Pay per call.
