Excel analytics: inspect, query (JSON rows), charts, and JSON-to-xlsx workbook writing.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 4 of 4 tools scored.
每个工具都有清晰且独特的用途：inspect查看结构，query查询数据，to_chart生成图表，write写入Excel。描述中明确区分了它们，没有重叠或混淆的可能。
命名统一使用'excel_'前缀，后接动词形式（inspect, query, write），但to_chart使用了介词结构，略微打破一致模式。整体仍可预测且清晰。
4个工具覆盖了Excel可视化的核心流程：结构查看、数据查询、图表生成、结果写入。数量适中，没有冗余，但可能缺少合并或格式调整等辅助功能。
工具集提供了从探索到输出完整闭环：先inspect了解结构，再用query获取数据，然后用to_chart生成图表，最后用write保存结果。没有明显遗漏，完全满足可视化目标。
excel_inspectAInspect查看 Excel 结构：各 sheet 的列名/类型/行数 + 前 N 行预览。免费(0 credit)。
出图前先调它看清有哪些 sheet、列、哪些列是数值，再据此选 chart_type 与 x/y。
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | No | 已上传到文件中转站的 Excel 文件 ID（与 data_base64 二选一） | |
| data_base64 | No | Excel(.xlsx) 内容的 base64（与 file_id 二选一，适合未上传的临时数据） | |
| preview_rows | No | 每个 sheet 预览的前 N 行 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the output (sheet names, column names/types/row counts, preview rows) and notes it's free (0 credit). While no output schema exists, the description covers key behavioral aspects. It does not contradict any annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines the tool's function, second provides usage guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately outlines what is returned. It explains the purpose and what to expect, but could mention that the tool is read-only and idempotent more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 aligns with the preview_rows parameter ('前N行预览') but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects Excel structure (columns, types, row counts, preview rows). It distinguishes from siblings like excel_query, excel_to_chart, and excel_write by framing it as a preliminary step for charting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling this before charting ('出图前先调它'), and explains why: to identify sheets, columns, numeric columns for chart_type and axes selection. Provides clear context without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
excel_queryAInspect查询 / 过滤 / 分组聚合 Excel，返回**实际数据行（JSON）**供 AI 直接分析（1 credit/次）。
取数工具，区别于 excel_to_chart（出图）和 excel_inspect（只看结构）。典型用法：
· 各地区销售额合计：group_by=["地区"], measures=["销售额"], agg="sum"
· 销量 Top5 商品：group_by=["商品"], measures=["销量"], agg="sum", sort_by="销量", descending=true, limit=5
· 每类别多少行：group_by=["类别"], agg="count"
· 筛失败订单明细：filters=[{"column":"状态","op":"eq","value":"失败"}]
返回 {ok, sheet, mode, columns, total_rows, matched_rows, returned_rows, truncated, rows[]}。
失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| agg | No | 聚合方式 sum/avg/count/min/max/median（默认 sum；count=数每组行数、无需 measures） | |
| limit | No | 最多返回多少行（取前 N / Top-N）；硬上限 1000 | |
| sheet | No | 目标工作表名；缺省第一个 sheet。先用 excel_inspect 看列名 | |
| columns | No | 明细模式：只返回这些列；缺省返回全部列 | |
| file_id | No | 已上传的 Excel 文件 ID（与 data_base64 二选一） | |
| filters | No | 行过滤条件（AND 组合），每项 {column, op, value}。op 可选：eq/ne/gt/ge/lt/le/contains/in/notnull/isnull。例：[{"column":"地区","op":"eq","value":"华东"},{"column":"金额","op":"ge","value":1000}] | |
| sort_by | No | 按哪一列排序（可为分组后的 measure 或 count 列） | |
| group_by | No | 分组维度列。给了就进聚合模式：按这些列分组，对 measures 求 agg | |
| measures | No | 聚合模式：要统计的数值列；缺省=所有数值列 | |
| descending | No | 降序排序（取 Top-N 常用 true） | |
| data_base64 | No | Excel(.xlsx) 内容 base64（与 file_id 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses behavioral traits: returns JSON rows, uses 1 credit per call, auto refund on failure, hard limit of 1000 rows. Does not mention if read-only, but implied by name and examples. Adding a note about data safety would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points and examples. Slightly verbose but every sentence adds value. Could trim redundant phrases but overall appropriate for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, description covers return format ({ok, sheet, mode, columns, ...}) and explains key param behavior (group_by activates aggregation). Provides enough context for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with concrete examples (e.g., filter syntax, group_by with measures) and explains the 'agg' default and 'count' usage. Examples illustrate parameter interaction, which is beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries/filters/groups Excel and returns JSON rows. Distinguishes from siblings 'excel_to_chart' (charting) and 'excel_inspect' (structure only) by saying '取数工具' (data extraction tool) and explaining typical usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidelines with multiple examples (e.g., group_by, filters) and states when to use this tool vs alternatives. Mentions '失败自动退款' (auto refund on failure) as a usage note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
excel_to_chartAInspect把 Excel 数据渲染成图表，产物存进你的文件中转站并返回下载 URL。
计费(生成类)：基础 3；高级图型 +2；矢量 SVG +1；大数据(>5000 行) +2。
调用失败自动退款。建议先 excel_inspect 看清列结构再出图。
返回: {ok, file_id, filename, format, credit_charged, download_url(15分钟有效),
chart_type, sheet, rows}
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X 轴/类别列名（饼图=标签列）；缺省取第一列 | |
| y | No | Y 轴数值列名，可单个或多个(数组)；缺省取所有数值列 | |
| agg | No | 聚合方式 count/sum/avg；缺省智能默认（分布类 饼/环→count 数每类多少条，其余→sum）。看「分布/各类别占比」用 count，无需 y（如性别男女各几人）；看「某数值在各类别的合计/平均」用 sum/avg 并给 y（如各地区销售额）。 | |
| fmt | No | 输出格式: png(默认) / svg(矢量, +1 credit) | png |
| sheet | No | 目标工作表名；缺省取第一个 sheet。先用 excel_inspect 查名字 | |
| title | No | 图表标题 | |
| series | No | 可选分组列：按它把 y 透视成多系列（分组/堆叠/多线） | |
| file_id | No | 已上传的 Excel 文件 ID（与 data_base64 二选一） | |
| options | No | 可选渲染项, 如 {"stacked":true,"bins":30,"cmap":"viridis","dpi":144} | |
| chart_type | Yes | 图表类型。标准型(基础3 credit): bar/column/line/pie/scatter/area/barh; 高级型(+2): stacked_bar/grouped_bar/radar/heatmap/histogram/box/donut。 | |
| data_base64 | No | Excel(.xlsx) 内容 base64（与 file_id 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses billing tiers, auto refund on failure, return fields including download URL validity, and that the product is stored in a file transfer station. It does not mention authentication or destructive actions, but it is sufficiently transparent for a chart generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (a few sentences in Chinese) and front-loaded with the main action. It includes billing info and usage tip, which are useful. Slightly more structure could improve readability, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all return fields. It covers the 11 parameters adequately and references excel_inspect for column structure. It could mention data size limits or error handling beyond billing, but overall it is comprehensive for a chart generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 11 parameters have schema descriptions, and the tool description adds significant value: it explains the agg parameter's default behavior per chart type, specifies credit costs for chart_type and fmt, and provides examples for options and series. This greatly enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: render Excel data into charts, store the result, and return a download URL. It also references the sibling tool excel_inspect, distinguishing it as a prerequisite step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using excel_inspect first and explains when to use count vs sum/avg for the agg parameter. However, it does not explicitly state when to use this tool over siblings like excel_query or excel_write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
excel_writeAInspect把 JSON 数据写成 Excel 工作簿（.xlsx），落文件中转站返下载 URL（上限 20 万单元格）。
补上「只能读不能写」的缺口：AI 算完的结果一步落成正式 Excel 交付。失败自动退款。
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | 数据行：对象列表 [{列:值},...]，或行数组 [[v1,v2],...]（需配 columns） | |
| columns | No | 列名（rows 为行数组时必填；对象列表时忽略） | |
| filename | No | 输出文件名（可选，自动补 .xlsx） | |
| sheet_name | No | 工作表名 | Sheet1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions the limit of 200k cells and auto-refund on failure, adding behavioral context. However, lacks details on file overwrite behavior, permissions, or rate limits, which would be valuable for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus one bullet, front-loaded with core purpose. Every sentence provides unique information: function (first sentence), context/limit (highlighted), and parameter notes. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description states it returns a download URL. Covers key constraints (cell limit, auto-refund) but omits details on error states, file size, or concurrent usage. For a tool with 4 parameters, it's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage. Description adds value by explaining the dual format for rows (object list vs. array), that columns are required for arrays, and that filename auto-appends .xlsx. These details clarify usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '把 JSON 数据写成 Excel 工作簿' (write JSON data to Excel workbook), specifying the resource (.xlsx), action (write), and delivery mechanism (return download URL). Differs from siblings (inspect, query, chart) as the only write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly addresses the gap of '只能读不能写' (only read, not write), guiding agents to use when needing to output data as Excel. Doesn't specify when not to use, but context implies alternatives are read/analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!