可视化图表生成MCP

目标

给券商用
解决开发人员和运营人员的可视化组件代码使用问题
给AI工具用(Mirror)

和AIME的区别

我们这个范围更广，不局限于金融。
我们支持更多的可视化形式(所有可视化都可以接入)

整合优于造轮子

其实也不全是，应该分工，有的人造轮子，然后让Agent进行整合与调度。
相当于有的人开发基座，有的人开发插件(Agent、MCP、Tool)。

我自己也可以搞一个大而全的Agent给我自己用，集成我生活、工作所需的所有Agent，类似Claude Code这个客户端。

可以参考这个文章中的Agent分类和职责：
https://mp.weixin.qq.com/s/RMxRX1cccJ09Zlk4GonePQ

价值

ToB券商价值

MCP相比API的优势

跟常规 API 不同，MCP 作为接口有一个好处。

常规 API 是对开发者的一种承诺，发布后不能轻易改变。但是，MCP 接口只供大模型调用，而大模型每次都会动态读取使用规范，因此我们能够随时更改 MCP 服务器，不会有任何问题。

– 史蒂夫·克劳斯，美国程序员
source

The fact that MCP is a difference surface from your normal API allows you to ship MUCH faster to MCP. This has been unlocked by inference at runtime

Normal APIs are promises to developers, because developer commit code that relies on those APIs, and then walk away. If you break the API, you break the promise, and you break that code. This means a developer gets woken up at 2am to fix the code

But MCP servers are called by LLMs which dynamically read the spec every time, which allow us to constantly change the MCP server. It doesn't matter! We haven't made any promises. The LLM can figure it out afresh every time

AI辅助规划

P1：
读取如下这个文件的内容，并基于这些内容，帮我设计可视化开发的AI Workflow和基建方案：
/Users/leozhou/Documents/Obsidian Vault/learning/tmp/AI基建.md

P2：
我们是做可视化需求和可视化组件开发的，比如类似ECharts、复杂关系图、叙事可视化、Web3D等组件和业务，不是前端开发；
我的目的是想先理清楚我们的业务和技术实现方案的分类，然后明确我们可以把那些能力抽象出来，形成为MCP，通过MCP的方式，在不同的环节辅助进行AI开发。

请重新思考并完善下这个文档。

P3：
这是我梳理的我们这边的工作内容的分类和一些注意事项，请结合这个内容，再深入分析优化下。

P4：
这个“已有的图表配置MCP”不是说我们已经做了这个MCP，而是指我们需要先将已有的一些图表封装为MCP，这个还没做呢。
然后我们先从讨论如何让AI用上“图表配置的MCP”开始吧

SVG的MCP

之前Napkin的那个搞下来，不就是一大批SVG的Tools吗！

我想写一个通过Prompt生成SVG可视化效果的MCP项目。
但是纯Prompt写SVG的可视化效果，还是有点难调的，可能生成的效果会不可控。
因此我想了一个办法，就是搞成DSL的形式以增强可控性。
我计划搞个生成SVG的Agent，将一些抽象出来的小元素封装为SVG的小元素Tools，AI组合调用这些Tools生成复杂点的效果，就像七巧板拼图一样。
这个如果搞出来，也可以弄个MCP给其他场景用。

你帮我分析下这个方案怎么样？

(精)方案分析文档：
[[SVG可视化-七巧板]]

实现方案

Final: 应该是以HTTP的形式提供，类似前端工作流和发布的MCP这样。
单独起个容器服务，用单独的路由搞这个。

几个核心Agent：意图、情绪、风格、表现形式
我们应该是提供一个服务出去，这个也是一个大的agent
然后这个服务内部使用了我们的各个子agent和工具

把不同的图表封装为tool
参考这个：
https://github.com/hustcc/mcp-echarts
可以将我们的VISALL、HIVIS、SD的各个Demo都整合到一起！
构建面向AI的MCP工具！

卧槽，我们的VISALL的layer设计，天然就是MCP的tool啊！
这个可以好好搞一波，而且能大吹特吹了！

使用流程

客户端安装MCP
获取Tools的信息
生成Tool的数据和参数
调用Tool，生成配置/图片
如果需要生成图片：上传公司的图片存储服务，返回图片链接
如果需要生成配置：返回配置信息
客户端SDK调用可视化配置，生成图表效果

按这个来看，不需要修改VISALL，只需要额外搞一层MCP即可。
要确定的是：业务方用的是VISALL还是SD？VISALL好一些吧

任务分解

如何渲染？

VISALL、StandardChart和各个组件库需要提供一个渲染的API，用于生成图片。

组件可能是非Canvas的。

搞个webcomponent的容器？HIVIS?

可以考虑直接将渲染所需的完整的JS作为输出，模板化既可。
VISALL的、ECharts的，都可以的:
layer-tool-模板-可渲染的完整代码

生成一个可嵌入的iframe？这样应用成本最低，就像之前的datav官网的嵌入方式那样。

应该基于layer还是case写tool？

用户真正需要的是case，LLM训练的也是case。
应该针对case写tool。

如何快速生成tool？

配置化，写一个管理工具，可以自动生成tool
tool的数据存储到数据库中，方便管理。

同创工坊支持npx本地运行MCP Server么？

这个得确定好，不然跑不动。

同创工坊
vtuber.aicubes.cn/agent-forge-front/#/agent-center?isDev=true

Tools封装

这个应该还好，写成模板，AI批量修改即可。
还是用分包的方式去搞这个事情。

得把layer改为zod的形式，补上描述信息。不写在VISALL里面，解耦出来，独立项目。
这个工作量应该不多，因为数据协议和layer协议基本上是统一的。

MCP协议接入

问题

如何解决tools太多的问题

详见这篇文章为模型创建结构化的技能树
如果工具太多，确实会导致给到 AI 的上下文太长。

我们来详细拆解一下这个问题：

当前的行为

按照 mcp-echarts 目前的设计，当服务启动时，它会通过 MCP 协议，一次性地将 src/tools/index.ts 中定义的所有工具（目前是17个）的完整描述（包括 name, description, 和 inputSchema 的 JSON Schema 形式）全部注册给客户端（AI Agent 所在的框架）。

如果未来这个库扩展到包含 50 个、100 个工具，那么这个初始注册的 JSON Schema 描述会变得非常庞大，如果 AI Agent 框架不加处理地将它们全部塞进 Prompt，会迅速消耗宝贵的上下文窗口（Context Window），并可能超出模型的长度限制。

现实中的解决方案

这个问题在实际的 AI Agent 架构中通常由客户端（AI Agent 框架）来解决，而不是由工具服务本身解决。主要有以下几种策略：

策略一：客户端进行“预筛选”或“路由”（Tool Routing）
- 一个成熟的 AI Agent 框架不会把所有可用的工具都放进最终的 Prompt 中。
- 它会有一个“路由”或“决策”步骤。首先，Agent 会分析用户的原始请求（例如“画一张饼图展示各产品销量占比”）。
- 然后，Agent 内部的一个小模型或者一个逻辑层会判断，用户的这个请求最可能与哪些工具有关。在这个例子中，它可能会只选择 generate_pie_chart 和通用的 generate_echarts 这两个工具的描述，而忽略 bar, line, radar 等其他所有工具。
- 最后，它只把这几个被选中的、最相关的工具的描述和用户的请求一起组合成最终的 Prompt 发送给大语言模型。
策略二：基于“语义搜索”的工具检索
- 对于拥有海量工具（成百上千个）的复杂系统，Agent 框架会把所有工具的描述（特别是 description 字段）预先存储在一个向量数据库中。
- 当用户请求到来时，框架会将用户请求的语义与数据库中的所有工具描述进行向量相似度搜索，找出最匹配的 Top-K 个工具。
- 然后，只将这 K 个最相关的工具注入到 Prompt 中。

mcp-echarts 的角色

mcp-echarts 作为一个“工具提供方”，它的职责是忠实地报告自己拥有哪些能力。它将自己所有的工具都“上架”，供客户端挑选。

而如何挑选、如何管理上下文长度，这个更复杂的“导购”任务，则由“顾客”——也就是 AI Agent 框架——来承担。

总结:

您的担忧是完全成立的，这是所有工具调用系统都需要面对的“上下文爆炸”问题。
mcp-echarts 目前的行为是“全量上报”自己的能力。
解决这个问题的责任方通常是调用 mcp-echarts 的客户端（AI Agent 框架），它会通过路由、筛选、语义搜索等方式，动态地选择最相关的工具放入 Prompt，从而有效管理上下文长度。

代码库

(TODO)流程

可以参考Magic UI的流程
https://magicui.design/docs/mcp

将功能拆解，使用时按流程分析和执行具体的tools：
macig-ui

子模块

范式组件库

SD和VISALL都可以，VISALL封装性更好一些。

在之前AI Builder的基础上继续做，反正都是写function calling的tools。
之前是所有图表的定义都放Prompt，现在得打散，放到tool里面(tool.description字段的信息)。比如area：

Generate a area chart to show data trends under continuous independent variables and observe the overall data trend, such as, displacement = velocity (average or instantaneous) × time: s = v × t. If the x-axis is time (t) and the y-axis is velocity (v) at each moment, an area chart allows you to observe the trend of velocity over time and infer the distance traveled by the area's size.

图表推荐

需要构建知识库。

配置代码生成(面向开发)

模板化即可，AIGC的Case可以起到这个效果。

到这一步，其实都不需要MCP，纯HTTP服务即可解决问题。
MCP只是起到简化和集成IDE的作用。

SSR图片生成(面向运营)

这个需要服务端了。

数据流程

安装MCP Server到用户本地
用户本地启动MCP Server
客户端通过Server获取工具列表(含工具描述信息)
客户端通过MCP协议发送工具调用请求
MCP Server接收请求并验证输入数据
MCP Server将请求转发到AntV Studio的API
外部API生成图表并返回URL
MCP Server将URL返回给客户端
客户端可以使用该URL查看或嵌入生成的图表

该项目展现了一个设计良好的微服务架构，通过MCP协议提供了标准化的图表生成能力，使大语言模型能够生成高质量的数据可视化。

图片生成: GPT-VIS-SSR

生成是调用这个接口：
https://antv-studio.alipay.com/api/gpt-vis
源码：
https://github.com/antvis/GPT-Vis/tree/main/bindings/gpt-vis-ssr

实践

1
2
3

我开发了一个类似ECharts的数据可视化的前端组件库，我想做一个MCP服务，方便使用这个组件库的开发人员，可以在VSCode中通过自然语言描述可视化需求，然后我给其返回对应的组件库的代码，嵌入他们的业务前端代码中。
针对这个场景，我该如何规划MCP Server和MCP Client的职责？
请帮我做下技术方案设计。

测试数据

[
  {
    "category": "A",
    "value": 0.08167
  },
  {
    "category": "B",
    "value": 0.01492
  },
  {
    "category": "C",
    "value": 0.02782
  }
]

资料

https://github.com/antvis/mcp-server-chart

TS的SDK:
https://github.com/modelcontextprotocol/typescript-sdk

MCP Inspector:
https://github.com/modelcontextprotocol/inspector

经典的MCP Server:
https://github.com/modelcontextprotocol/servers

关于可视化组件技术选型的思考上一篇

weekly-summary-20250518 下一篇