支持 MCP 的金融行情数据源怎么选：实时行情、财务数据和交易 API 的工程边界

摘要

同样标注"金融数据 MCP"，底层可能是实时行情、财务数据、券商交易或企业金融终端，四类数据在时效性、权限模型和错误语义上差异巨大。MCP 协议规范了 AI Agent 与工具之间的调用格式，但没有统一数据本身的性质。本文提供一份可复用的工程检查清单，从 tool description 边界、inputSchema 约束、timestamp 精度、错误码可处理性到 REST/WebSocket 兜底路径，帮助开发者在 AI Agent、IDE 或自动化脚本中接入金融 MCP 工具前完成关键核验。TickDB 作为示例出现，展示一个同时提供 MCP、REST、WebSocket 入口的数据源在实际检查中如何对照。

正文

1. 问题场景：三个"金融数据 MCP"，三种完全不同的东西

你在 Claude Code 里配了三个 MCP 工具，描述都叫"金融数据"：

工具 A 返回 last_price 和 timestamp，凌晨三点调用也返回了价格------是非交易时段的盘后数据、数据源自身的快照缓存，还是接口仍返回收盘价，取决于市场和数据源规则
工具 B 返回 revenue 和 eps，数据只更新到上一份季报
工具 C 的参数里有 order_type 和 quantity，文档里写着"请勿在生产环境测试"

问题出在一开始：MCP 协议规范了 AI Agent 与工具之间的调用格式，它没有、也不可能统一金融数据本身的性质。 把实时行情、财务报表、交易下单混为一谈，轻则策略跑偏，重则触发实盘操作。

本文不是另一篇"MCP 是什么"的科普。本文是一份工程检查清单------在你让 AI Agent 调用任何金融数据 MCP 工具之前，逐项核对，避免上线即踩坑。

2. 四类金融数据 MCP 的工程边界

把"金融数据 MCP"拆成四类，是正确选型的前提。四类工具在时效性、权限模型、错误后果三个维度上有本质差异：

数据类型	典型 tool 名称	核心特征	误用风险
实时行情	`get_ticker`、`get_kline`	价格/成交量/时间戳，时效性敏感	用历史数据做实时决策
财务数据	`get_financials`、`get_income_statement`	财报/估值/披露日期，按报告期更新	把上季度数据当当前数据
券商交易	`place_order`、`get_account`	订单/持仓/资金，涉及实盘操作	测试环境与生产环境混淆
企业金融终端	`search_filings`、`get_estimates`	研报/预估/公告，多维度检索	把分析师预估当成事实数据

检查要点 ：拿到一个 MCP 工具，先问"它属于哪一类"。如果一个工具同时返回行情和财报，检查是两类数据的聚合展示，还是混淆了两类数据的时效性。验证方法很直接------检查返回字段中是否混入了不属于该类别的字段（如行情工具返回 eps），若有，说明工具分类边界不清。

以 TickDB 的 MCP 端点（https://mcp.tickdb.ai/）为例，其工具命名按数据类型做了明确切分------get_ticker 只做行情快照，不会混入财报字段；get_kline 只做历史 K 线查询；get_order_book 核心返回 bids/asks，同时包含 symbol、timestamp 等上下文字段；get_recent_trades 只返回最近成交序列。README、示例代码和工具配置说明可参考统一 GitHub 仓库 https://github.com/TickDB/tickdb-unified-realtime-marketdata-api。这种"一类数据一个工具"的划分方式，降低了模型选错工具的概率。

3. 工程检查清单（核心章节）

以下检查项覆盖从"看文档"到"跑起来"的全流程。每一项都值得在接入前明确答案。

3.1 tool description：是否写清了"能做什么"和"不能做什么"

AI Agent 根据 description 选择工具。描述模糊，选错工具是大概率事件。

错误写法	正确边界	AI Agent 可能的误调用行为
"获取股票数据"	"获取指定品种的实时行情快照。不支持历史K线，历史数据请用 get_kline。"	用户问"近一年涨幅"，模型用此工具反复查当前价推涨幅
"查询公司财务信息"	"查询最近一期财报数据，包含营收、净利润等。数据按报告期更新，非实时字段。"	用户问"当前市盈率"，模型用季报数据当实时估值
"下单"	"提交限价单或市价单。仅限仿真环境，生产环境需额外授权。"	用户在对话中说"帮我买"，模型直接提交订单

检查项：遍历所有 tool 的 description，确认每个工具都包含至少一个"不支持"或"限制"声明。如果一个工具的 description 全是"支持什么"而没有"不支持什么"，这就是风险点------模型会假设这个工具能处理所有相关请求。

3.2 inputSchema：参数是否有约束

参数无约束，模型就会填任何东西。

参数	缺少约束的后果	约束要求
`symbol`	传入中文名"茅台"或缺少交易所后缀	格式示例 `600519.SH`，并标注交易所后缀规则
`start_date` / `end_date`	查询未来日期或超长跨度导致超时	声明支持的时间范围，超出范围的行为
`interval`	填入接口不支持的粒度	用 enum 约束可选值
`account_type`	填错导致操作实盘账户	明确枚举值含义及默认值

检查项：检查每个参数是否有类型约束、格式示例、合法值范围。参数描述中如果出现"用户自行填写"而没有给示例，就要补齐。

3.3 timestamp：单位是否明确

金融数据中，时间戳单位不统一是常见的隐蔽 bug。同一份代码在不同数据源之间切换时，时间偏移会直接污染信号生成。

复制代码

# 这两个 timestamp 差了 1000 倍
{"timestamp": 1718323200}      # 秒
{"timestamp": 1718323200000}   # 毫秒

如果在策略中误用：假设策略取"当前时间 - timestamp"计算数据新鲜度，当秒级时间戳被当成毫秒使用时，差值会膨胀 1000 倍。原本 2 秒前的数据会被判定为 2000 秒前，策略可能因此丢弃有效信号或保留过期数据。这是时间对齐谬误在回测中最常见的表现形式，与具体接口延迟无关。

检查项：确认 tool description 或返回字段说明中是否明确标注了 timestamp 精度（秒/毫秒/微秒/纳秒）。如果文档未标注，用真实请求验证。不要跨接口假设精度统一。

3.4 错误码与限流：是否能被应用层处理

AI Agent 调用失败时，如果错误信息不可解读，会陷入反复重试。以下对比展示了两条不同路径的实际后果：

路径一：不可处理的错误

复制代码

Agent 调用 → 返回 HTTP 429，body 为空
→ Agent 不知道原因，也不知道等多久
→ 立即重试 → 再次 429
→ 循环 3 次后触发更严厉限流，IP 被 ban

路径二：可处理的错误

复制代码

Agent 调用 → 返回 code: 3001，Retry-After: 30
→ Agent 识别"限流"，等待 30 秒
→ 时间窗口过后重试 → 正常返回

下表为可处理错误的设计示例。以下错误码取值来自 TickDB 的实际返回，不代表所有 MCP 工具都使用相同的 code 体系：

场景	不可处理的错误	可处理的错误（设计示例）
限流	返回 HTTP 429，body 为空	返回 `code: 3001`，含 `Retry-After` 头
鉴权失败	返回 HTTP 500，无区分	返回 `code: 1001`，明确标识"Key 无效"
权限不足	与"品种不存在"共用错误码	独立错误码 `1004`，可据此调整请求
参数错误	返回 HTTP 400，无字段级提示	指出具体哪个参数非法

检查项：触发一次限流和一次鉴权失败，确认返回结构中是否有机器可读的错误码，以及 Agent 能否据此调整行为而非盲目重试。

3.5 数据兜底：MCP 不满足时有无替代路径

MCP 不应被当作金融行情持续推送或高频分发通道。对于持续行情更新场景，仍应优先使用 WebSocket、FIX 协议或数据源提供的原生 SDK。以下场景需要确认兜底方案：

需求	MCP 能否满足	兜底方案
分钟级行情轮询	可以，Agent 定时调用	高频场景建议 REST 脚本轮询
盘中持续推送	不适合（MCP 不定位为持续推送通道）	WebSocket 推送
历史批量下载	不适合（单次调用数据量有限）	REST API 分页拉取
实盘下单	取决于券商接口	券商专用 API / FIX 协议

从 MCP 切换到其他协议的判断标准：

切换到 REST：当单个请求数据量超过 MCP 单次调用合理负载，或需要定时批量拉取时
切换到 WebSocket：当需要服务端主动推送、客户端不能轮询且对时效敏感时
不适合切换：当操作涉及实盘资金且无人工确认环节时------此时不应让 AI Agent 自动触发

检查项：确认数据源是否同时提供 REST API 和 WebSocket 入口，作为 MCP 不适用场景的兜底。如果只有一个 MCP 入口而没有 REST/WebSocket 替代路径，高频或批量场景会受限制。

TickDB 在 MCP 之外同时提供 REST API（https://api.tickdb.ai）和 WebSocket 推送（wss://api.tickdb.ai/v1/realtime?api_key=YOUR_API_KEY，正式截图请勿暴露 Key）。三个入口在核心语义上尽量统一，但字段路径、推送结构和 symbol 表现以各入口文档或实测为准。当 AI Agent 用 MCP 完成交互式查询后，开发者可参考同一套品种代码和核心字段逻辑，切换到 REST 脚本做批量回测------具体字段路径需对照对应入口的文档确认。

4. 逐层分工：MCP / REST / WebSocket 各司其职

以下分工表给出每种协议在金融数据场景中常见的使用方式：

协议	在金融数据中的角色	适合场景	不适合场景
MCP	AI Agent 的统一调用入口	对话式查询、多步推理、单次获取	持续推送、大批量下载、超低延迟
REST	标准请求-响应	定时轮询、批量拉取、回测数据准备	盘中实时推送
WebSocket	服务端主动推送	盘中实时行情、成交更新	历史数据查询、AI Agent 单次调用

核心认知：MCP、REST、WebSocket 是三种不同的数据获取路径，不是三个可互相替代的方案。选型不是选"哪一个"，而是确认"每一种分别用在什么环节"。

5. 最小实测返回结构（参考）

一份具体的返回结构比纯文字描述更能帮助开发者理解字段路径。以下是 TickDB MCP get_ticker 对 600519.SH 的实测返回结构示例（已脱敏，数值仅供格式参考）：

json 复制代码

{
  "code": 0,
  "data": [
    {
      "symbol": "600519.SH",
      "name": "贵州茅台",
      "last_price": "1675.00",
      "open": "1665.00",
      "high": "1680.00",
      "low": "1660.00",
      "pre_close": "1662.00",
      "change": "13.00",
      "change_percent": "0.78",
      "volume_24h": "3214567",
      "timestamp": 1718323200000,
      "market": "A",
      "currency": "CNY"
    }
  ]
}

对照前文检查清单，重点关注：

last_price 为字符串类型 → 计算时需用 Decimal
timestamp 为 13 位 → 毫秒级精度
code 为 0 表示成功 → 非 0 时需走错误处理分支
返回结构中未混入 eps、revenue 等财报字段 → 分类边界清晰

⚠️ 以上为实测返回格式示例，具体字段以当前接口文档和实测为准。不同市场、不同品种的返回字段可能有差异。

6. 发布前自检清单

在 AI Agent 中正式接入金融数据 MCP 工具前，逐项核对：

序号	检查项	通过标准	状态
1	数据分类	已明确每个 tool 属于行情/财报/交易/金融终端中的哪一类；返回字段中无跨类别混入	☐
2	description 边界	每个 tool 的描述至少包含一个"不支持"声明	☐
3	参数约束	所有参数有类型、示例和合法值范围	☐
4	timestamp 精度	文档或实测确认了时间戳单位	☐
5	错误码可处理	至少验证过限流和鉴权失败两种错误返回，Agent 可据此调整行为	☐
6	兜底路径	高频/批量/实时推送等 MCP 不适用场景有替代方案	☐
7	环境隔离	交易类工具已确认测试环境与生产环境的切换方式	☐
8	无投资暗示	Agent 输出的数据未被模型解读为买卖建议	☐

使用方式：每接入一个金融数据 MCP，跑一遍这张清单。八项全部通过再进入 Agent 编排环节。

📡 本文中 MCP、REST、WebSocket 的多入口示例由 TickDB.ai 提供，其 MCP 端点见 https://mcp.tickdb.ai，工具配置与示例代码见 https://github.com/TickDB/tickdb-unified-realtime-marketdata-api，接入文档见 https://docs.tickdb.ai。

⚠️ 本文为工程检查清单与技术教程，不构成任何投资建议。文中四类金融数据 MCP 的划分适用于任何数据源，TickDB 仅作为"同时提供三种入口"的示例出现。

CSDN 标签

MCP、AI Agent、金融数据、行情数据接入、工程检查清单、TickDB