最近做 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 和工具 schemaMCP 的优势会比较明显。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 ServerHTTP 工具 / 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.cnMCP 场景可以让 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 的数据接入和工程架构不构成任何投资建议。