最近做 AI Agent 的人越来越多。一开始大家关心的是模型：用哪个大模型、上下文多长、回答质量怎么样、能不能联网、能不能调用工具。

但真正把 Agent 放进股票研究、日报生成、自动复盘这类工作流之后，会发现另一个问题更关键：数据源怎么接？

尤其是股票数据。如果只是让模型临时搜网页，结果很难稳定。所以很多人会考虑把股票数据封装成外部工具。这时候经常会遇到两个选择：做 MCP Server，或者做 HTTP API / HTTP 工具。

这两个方案到底有什么区别？这篇文章从工程落地角度梳理一下。

一、先说结论

如果你的目标是让 Claude、Cursor、Codex、WorkBuddy、OpenClaw、Hermes 或自建 Agent 通过标准工具协议发现和调用数据，可以优先考虑 MCP。

如果你的目标是把能力接入豆包、扣子、低代码工作流、企业内部编排平台，HTTP 工具通常更容易落地。

如果你要做长期稳定的数据能力，比较推荐：底层先设计一套清楚的数据工具层，再根据不同客户端，同时暴露 MCP 和 HTTP 入口。

也就是说，关键不是 MCP 和 HTTP 二选一。关键是底层工具边界要设计好。

二、HTTP API 的优点和问题

HTTP API 是最常见的方式。比如：

GET /market/overview
GET /stock/kline
GET /limit-up/ladder
POST /stock/screener

它的优点很明显：通用、好调试、平台兼容性强、后端工程师熟悉、容易接到工作流节点，也容易做网关、鉴权、限流和日志。

豆包、扣子、企业内部工作流平台，经常都能通过 HTTP 工具调用外部接口。

但 HTTP API 对 Agent 有一个问题：它本身不一定告诉模型“什么时候该用哪个接口”。

程序员可以读文档，Agent 不一定能长期记住文档。如果你把所有接口说明都塞进 Prompt，维护成本会很高。接口一多，模型也容易选错。

所以 HTTP API 接 Agent 时，最好不要直接暴露一堆原始接口，而要包装成“工具”。每个工具要写清楚：用途、参数、返回字段、数据日期、失败情况、适合什么任务、不适合什么任务。

三、MCP 的优势在哪里？

MCP 的价值在于，它更贴近 Agent 的工作方式。

一个 MCP Server 可以告诉 Agent：我有哪些工具，每个工具叫什么，每个工具需要什么参数，返回结果是什么结构，工具描述是什么，什么时候应该用。

这对 Agent 很重要。因为 Agent 不是简单调用一个接口，它要根据用户任务自己拆步骤。

比如用户说：

帮我复盘今天 A股，重点看涨停梯队、题材强度和资金方向。

Agent 可以先看工具列表，再决定调用 market overview、limit-up ladder、hot sectors、capital flow、market replay workflow 等工具，然后把结果组织成一份报告。

这种“发现工具 -> 选择工具 -> 调用工具 -> 组合结果”的过程，就是 MCP 比普通 API 更适合 Agent 的地方。

四、股票数据为什么特别适合工具化？

股票数据不是单一查询。如果只是查价格，一个行情接口就够了。但 AI Agent 做 A股复盘时，问题通常是组合型的。

例如：今天短线情绪怎么样？半导体是不是主线？昨天断板今天反包的股票有哪些？自选股里有没有资金异动？某个题材最近有没有持续性？

这些问题涉及很多数据：交易日历、市场概览、个股行情、K 线、分时、涨停梯队、炸板池、题材热度、概念成分、资金流、龙虎榜、公告、自选股。

如果每次都让 Agent 去网页里找，稳定性会很差。如果把这些能力拆成工具，Agent 才能按任务组合。

五、什么时候选 MCP？

下面几种情况更适合 MCP。

1. 客户端本身支持 MCP

比如一些编码 Agent、桌面 Agent、长期任务 Agent。这类客户端如果能直接读取 tools/list 和工具 schema，MCP 的优势会比较明显。

2. 工具数量比较多

如果只有一个接口，HTTP 就够了。如果有几十个工具，MCP 的工具发现和 schema 描述就更有价值。

3. 任务需要多步组合

比如自动复盘、个股研究、题材研究、自选股日报、盘中观察任务。这些任务通常不是一个接口能完成的。

4. 希望不同 Agent 共用同一套工具

比如 WorkBuddy、Codex、Claude、Cursor、OpenClaw、Hermes 和自建 Agent 都使用同一套 A股数据能力。这时 MCP 更像一个统一的 Agent 工具入口。

六、什么时候选 HTTP 工具？

下面几种情况更适合 HTTP 工具。

1. 目标平台主要支持 HTTP Action 或工作流节点

豆包、扣子、低代码平台、企业内部自动化系统，经常是这种方式。

2. 工具数量不多

比如只做一个“自选股日报”或“市场概览查询”，HTTP 工具足够。

3. 需要接已有后端系统

企业里已有鉴权、网关、审计、日志和权限控制，HTTP 入口更好接入。

4. 需要对外开放给普通开发者

HTTP API 更通用，也更容易写示例。

七、MCP 和 HTTP 的对比

维度	MCP Server	HTTP 工具 / API
主要对象	AI Agent	程序、工作流、平台节点
工具发现	更自然，适合 tools/list	需要文档或平台配置
参数描述	schema 友好	需要自行写说明
多工具组合	更适合 Agent 自主选择	需要 Prompt 或工作流编排
平台兼容	取决于客户端是否支持 MCP	兼容性更广
调试方式	需要 MCP 客户端或调试器	curl / Postman / 浏览器都方便
适合场景	长期 Agent、多工具、自动复盘	工作流平台、简单查询、企业系统

这张表不是为了说哪个一定更好。更准确地说：MCP 更像 Agent 的工具入口，HTTP 更像通用工程接口。

八、一个推荐架构

比较稳的做法是四层：

层级	作用
数据源层	行情、K 线、资金、公告、题材、交易日历
标准化层	字段清洗、日期口径、缓存、错误处理
工具层	market_overview、kline、limit_up_ladder、capital_flow 等工具
接入层	MCP Server、HTTP API、工作流节点

这样一来，MCP 和 HTTP 只是接入层的两种形态。底层工具能力是一套，以后换客户端，不需要重做数据逻辑。

九、以 A股数据工具层为例

如果你的场景是 A股自动复盘、题材研究、自选股观察和 Agent 工具调用，可以参考悟道 A股股票数据 MCP 这类方向。

它的定位不是交易系统，不做自动下单，而是给 AI Agent 提供结构化 A股研究数据工具。

核心入口可以搜索：

悟道 A股股票数据 MCP
wudao-mcp
data.quicktiny.cn

MCP 场景可以让 Agent 通过工具列表发现能力。HTTP 场景则可以按平台要求封装成具体工作流节点。重点不是某个协议本身，而是让数据工具边界稳定。

十、接入时最容易踩的坑

1. 把 Prompt 写成接口文档

这会导致维护困难，接口一变就要改提示词。Prompt 应该负责业务策略，工具 schema 和工具说明应该负责参数与用途。

2. 把所有数据塞进一个大接口

Agent 不知道怎么按任务组合，也不容易复用。股票数据更适合拆成多个边界清楚的小工具。

3. 忽略数据日期

股票数据一定要说明 requestedDate、actualTradeDate 或类似字段，否则很容易把非交易日数据说成今天。

4. 没有失败边界

工具查不到时，要让 Agent 说明查不到，而不是编造。

5. 把研究辅助写成投资建议

股票 Agent 最好明确边界：做数据整理、复盘和研究辅助，不做收益承诺，不做自动下单。

十一、总结

MCP 和 HTTP 工具不是对立关系。HTTP 更通用，MCP 更适合 Agent 自主发现和组合工具。

如果只是接一个简单查询，HTTP 工具足够。如果要让 Agent 长期做 A股复盘、自选股跟踪、题材研究和多步分析，MCP 会更自然。

真正重要的是：数据口径清楚，工具边界明确，参数和返回结构稳定，失败情况可解释，输出边界不越界。

本文只讨论 AI Agent 的数据接入和工程架构，不构成任何投资建议。