@lmdat/cafef-financial-mcp
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., "@@lmdat/cafef-financial-mcpGet balance sheet for FPT last 4 quarters"
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.
@lmdat/cafef-financial-mcp
Local MCP server (Node.js + TypeScript) lấy dữ liệu báo cáo tài chính doanh nghiệp Việt Nam (Bảng cân đối kế toán, Báo cáo kết quả kinh doanh, Báo cáo lưu chuyển tiền tệ) trực tiếp từ cafef.vn — không cần PDF, không cần OCR.
Yêu cầu
Node.js 18+
Related MCP server: ashare-mcp
1. Cài đặt
npm install2. Build
Lệnh | Output | Dùng khi nào |
|
| Phát triển/debug, code dễ đọc (3 file vì có 3 file |
|
| Dùng để chạy thật / publish |
|
| Muốn code khó đọc hơn khi chia sẻ (không phải mã hóa, chỉ gây khó đọc) |
Build tối thiểu 1 lần trước khi cấu hình opencode ở bước tiếp theo.
3. Cấu hình trong opencode
Có 2 cách trỏ tới MCP server, chọn 1 trong 2. Server này không cần biến môi trường nào (API của cafef.vn là công khai, không cần API key).
Cách 1 — Trỏ trực tiếp đến file (đơn giản, không cần publish)
"cafef-financial": {
"type": "local",
"command": [
"node",
"/duong-dan-tuyet-doi/cafef-financial-mcp/dist/index.js"
],
"enabled": true
}Thay /duong-dan-tuyet-doi/... bằng đường dẫn thật trên máy đang chạy opencode.
Cách 2 — Dùng qua npm package (cần publish trước)
Nếu package đã được publish lên npm registry:
"cafef-financial": {
"type": "local",
"command": [
"npx",
"-y",
"@lmdat/cafef-financial-mcp@latest"
],
"timeout": 15000,
"enabled": true
}Lưu ý:
npx -ycó độ trễ khởi động (vài giây, do phải resolve package qua registry trước khi chạy) — có thể gây race condition với bước opencode hỏitools/listlúc tạo session mới. Nếu gặp tình trạng tool không load được, ưu tiên Cách 1, hoặc cài global (npm install -g @lmdat/cafef-financial-mcp) rồi gọi trực tiếp tên lệnh ("command": ["cafef-financial-mcp"]) để loại bỏ độ trễ này.
4. Danh sách tool
Tool | Mô tả |
| Bảng cân đối kế toán |
| Báo cáo kết quả kinh doanh |
| Báo cáo lưu chuyển tiền tệ |
Tham số chung cho cả 3 tool:
Tham số | Bắt buộc | Default | Ghi chú |
| Có | — | Mã cổ phiếu, ví dụ |
| Không |
|
|
| Không |
| Số kỳ gần nhất cần lấy (1-20) |
5. Ví dụ câu lệnh trong opencode
Lấy bảng cân đối kế toán của FPT 4 quý gần nhất
Lấy báo cáo kết quả kinh doanh VNM theo năm, 5 năm gần nhất
So sánh lưu chuyển tiền từ hoạt động kinh doanh của HPG và FPT6. Cấu trúc dữ liệu trả về
Mỗi tool trả về 1 object NormalizedReport (xem src/types.ts) gồm:
periods: danh sách kỳ, đã sắp xếp tăng dần theo thời gianitems: toàn bộ chỉ tiêu đọc được, mỗi item cócode,name,values(mảng theo kỳ)keyMetrics: các chỉ tiêu quan trọng đã trích sẵn theo tên dễ đọc (ví dụtong_tai_san,doanh_thu_thuan,luu_chuyen_tu_hdkd...)missingPeriods: danh sách kỳ bị phát hiện thiếu dữ liệu (toàn 0 bất thường) — giá trị ở các kỳ này được trả vềnull, không dùng số 0 thật để tính toán
7. Lưu ý quan trọng
Mã chỉ tiêu (
code) của Cash Flow có tiền tố theo nhóm (HDKD_xx,HDDT_xx,HDTC_xx), khác với Balance Sheet/Income Statement (code số thuần như270,10).Dữ liệu lấy từ API công khai cafef.vn — là dữ liệu tổng hợp bởi bên thứ ba, nên đối chiếu lại với BCTC gốc nếu cần độ chính xác cao (ví dụ dùng cho quyết định đầu tư thật).
8. (Tùy chọn) Publish lên npm để dùng theo Cách 2
npm login # nếu chưa đăng nhập npm
npm run build:min
npm publish # đã có publishConfig.access=public trong package.jsonKiểm tra trước khi publish thật:
npm run build:min && npm pack --dry-run9. Phát triển thêm
npm run dev # tsc --watch, tự build lại khi sửa code trong src/Available Tools
3 toolsget_balance_sheetLấy Bảng cân đối kế toánA
Lấy dữ liệu Bảng cân đối kế toán (Balance Sheet) của 1 mã cổ phiếu Việt Nam từ API công khai cafef.vn. Trả về các chỉ tiêu chuẩn (tổng tài sản, nợ phải trả, vốn chủ sở hữu, phải thu ngắn hạn, hàng tồn kho...) theo nhiều kỳ gần nhất, đã chuẩn hóa số liệu (number thật) và phát hiện kỳ thiếu dữ liệu.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Mã cổ phiếu, ví dụ FPT, VNM, HPG | |
| pageSize | No | Số kỳ gần nhất cần lấy (mặc định 4) | |
| typeTime | No | QUY = lấy theo quý, NAM = lấy theo năm | QUY |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the data source (cafef.vn), standardization of numbers, detection of missing periods, and that it returns multiple periods. This adds useful behavioral context beyond a bare read 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?
The description is a single, clear, front-loaded paragraph with no unnecessary words. It immediately conveys the tool's purpose and key features.
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 annotations or output schema, the description provides sufficient context: source, features (normalization, missing period detection), and basic behavior. Lacks mention of output format or error handling, but adequate for a 3-parameter 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 coverage is 100% with descriptions for all three parameters. The description adds context about the tool's output (standard indicators) but does not enhance understanding of individual parameter semantics 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 it retrieves balance sheet data for a Vietnamese stock ticker from cafef.vn, listing standard indicators and features like number normalization and missing period detection. This distinguishes it from sibling tools for cash flow and income statement.
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 balance sheet data but does not explicitly state when to use this tool versus alternatives. No 'when not to use' or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cash_flowLấy Báo cáo lưu chuyển tiền tệA
Lấy dữ liệu Báo cáo lưu chuyển tiền tệ (Cash Flow Statement) của 1 mã cổ phiếu Việt Nam từ API công khai cafef.vn. Trả về lưu chuyển tiền thuần từ hoạt động kinh doanh, tiền và tương đương tiền cuối kỳ theo nhiều kỳ gần nhất, đã chuẩn hóa số liệu và phát hiện kỳ thiếu dữ liệu. Lưu ý: mã chỉ tiêu (code) trong báo cáo này có tiền tố theo nhóm (HDKD_xx, HDDT_xx, HDTC_xx), khác với Balance Sheet/Income Statement.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Mã cổ phiếu, ví dụ FPT, VNM, HPG | |
| pageSize | No | Số kỳ gần nhất cần lấy (mặc định 4) | |
| typeTime | No | QUY = lấy theo quý, NAM = lấy theo năm | QUY |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains data source, normalization, missing period detection, and that it returns multiple periods. It does not mention side effects, which is appropriate for a 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?
Description is a single coherent paragraph that front-loads the purpose and then adds details. It could be slightly more structured but is not overly long.
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, description covers key output aspects (returned metrics, multiple periods, normalization, missing period detection). It does not detail exact structure but provides sufficient context for an AI agent to understand the tool's function.
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 parameter descriptions. The description adds value by explaining that code prefixes differ from other statements, aiding interpretation of results. However, parameter details like pageSize and typeTime are already fully described in 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 retrieves Cash Flow Statement data for a Vietnamese stock from cafef.vn API, lists specific returned metrics (cash flow from operations, cash equivalents), and distinguishes from siblings by noting different code prefixes.
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 cash flow analysis and contrasts with Balance Sheet/Income Statement by mentioning different code prefixes, but does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_income_statementLấy Báo cáo kết quả kinh doanhA
Lấy dữ liệu Báo cáo kết quả hoạt động kinh doanh (Income Statement) của 1 mã cổ phiếu Việt Nam từ API công khai cafef.vn. Trả về doanh thu thuần, lợi nhuận gộp, lợi nhuận sau thuế theo nhiều kỳ gần nhất, đã chuẩn hóa số liệu và phát hiện kỳ thiếu dữ liệu.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Mã cổ phiếu, ví dụ FPT, VNM, HPG | |
| pageSize | No | Số kỳ gần nhất cần lấy (mặc định 4) | |
| typeTime | No | QUY = lấy theo quý, NAM = lấy theo năm | QUY |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It reveals that data is normalized and missing periods are detected, but lacks information on authentication, rate limits, or side effects. The description is adequate but not thorough.
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-loaded with purpose and followed by details about returned data. It is concise but could benefit from structuring into bullet points for easier scanning.
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 3 parameters and no output schema. The description lists returned data items but does not clarify the output format (e.g., array of objects). It also omits authentication or usage constraints, making it incomplete for a multi-period data 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds context about overall output but does not enhance parameter-specific meaning beyond what the schema already provides.
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 income statement data for a Vietnamese stock ticker from the cafef.vn API. It specifies the data items (revenue, gross profit, net profit) and mentions normalization and missing period detection. The purpose is distinct from sibling tools (balance sheet, cash flow).
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 guide when to use this tool versus alternatives. Sibling names imply differentiation, but no direct instruction or context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool retrieves a distinct financial statement (balance sheet, cash flow, income statement) with no overlap. Agents can clearly differentiate based on statement type.
All tools follow the consistent pattern 'get_<statement_name>', using snake_case and clear verbs. No naming anomalies or mixed conventions.
Three tools perfectly match the domain of financial statement retrieval. The count is focused and appropriate without being too few or too many.
The three core financial statements are covered, which is comprehensive for most analyses. Minor gaps like statement of changes in equity are acceptable for this scope.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Unlock the power of real-time financial data with our Finance MCP. Easily retrieve the latest
SEC MCP — SEC EDGAR public APIs (free, no auth)
Related MCP Servers
- AlicenseBqualityFmaintenanceVietnamese Financial Markets Data MCP Server providing real-time quotes, financials, and technical indicators.35511MIT
- AlicenseAqualityDmaintenanceMCP server for Chinese A-share (Shanghai/Shenzhen/Beijing) financial statements: pull annual reports, run 4 industry-aware accounting cross-checks, and peer-compare companies with derived avg-equity ROE.35MIT
- AlicenseBqualityDmaintenanceMCP server for Vietnamese stock market data, enabling AI assistants to access stock history, financials, company info, and global market data through 21 tools.21102MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for analyzing SEC filings (10-K, 10-Q, 8-K) with industry-aware financial extraction and BERT-based NLP.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/lmdat/cafef-financial-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server