Skip to main content
Glama
lmdat

@lmdat/cafef-financial-mcp

by lmdat

@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 install

2. Build

Lệnh

Output

Dùng khi nào

npm run build

build/index.js, build/cafefClient.js, build/types.js

Phát triển/debug, code dễ đọc (3 file vì có 3 file.ts nguồn)

npm run build:min

dist/index.js (1 file, đã gộp + minify)

Dùng để chạy thật / publish

npm run build:obfuscate

dist/index.js (đã obfuscate)

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 -y có độ 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ỏi tools/list lú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ả

get_balance_sheet

Bảng cân đối kế toán

get_income_statement

Báo cáo kết quả kinh doanh

get_cash_flow

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ú

ticker

Mã cổ phiếu, ví dụFPT, VNM, HPG (1-10 ký tự)

typeTime

Không

QUY

QUY = theo quý, NAM = theo năm

pageSize

Không

4

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à FPT

6. 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 gian

  • items: 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.json

Kiểm tra trước khi publish thật:

npm run build:min && npm pack --dry-run

9. Phát triển thêm

npm run dev   # tsc --watch, tự build lại khi sửa code trong src/

Available Tools

3 tools
get_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesMã cổ phiếu, ví dụ FPT, VNM, HPG
pageSizeNoSố kỳ gần nhất cần lấy (mặc định 4)
typeTimeNoQUY = lấy theo quý, NAM = lấy theo nămQUY

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesMã cổ phiếu, ví dụ FPT, VNM, HPG
pageSizeNoSố kỳ gần nhất cần lấy (mặc định 4)
typeTimeNoQUY = lấy theo quý, NAM = lấy theo nămQUY

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesMã cổ phiếu, ví dụ FPT, VNM, HPG
pageSizeNoSố kỳ gần nhất cần lấy (mặc định 4)
typeTimeNoQUY = lấy theo quý, NAM = lấy theo nămQUY

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

A4.1/5.0
Disambiguation5/5

Each tool retrieves a distinct financial statement (balance sheet, cash flow, income statement) with no overlap. Agents can clearly differentiate based on statement type.

Naming Consistency5/5

All tools follow the consistent pattern 'get_<statement_name>', using snake_case and clear verbs. No naming anomalies or mixed conventions.

Tool Count5/5

Three tools perfectly match the domain of financial statement retrieval. The count is focused and appropriate without being too few or too many.

Completeness4/5

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

ActivitySlowing
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP 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.
    3
    5
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for analyzing SEC filings (10-K, 10-Q, 8-K) with industry-aware financial extraction and BERT-based NLP.
    1
    MIT

Latest Blog Posts

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