Skip to main content
Glama
chang0911

丝路E投财务引擎 MCP 适配层

by chang0911

generate_ppt_html

Converts content HTML into a self-contained presentation file with inlined Plotly.js for offline use, returning a 72-hour download link by default.

Instructions

演示文稿封装:内容HTML → 自包含HTML(Plotly.js内联,离线可用)。先用 ppt_extract_data 取数并撰写内容,再调本工具出成品(成品常达2~4MB,默认返回72h下载短链(return_mode="base64" 可回退))。HTML结构要求先看 get_skill_instructions(skill=ppt)。前置:需先调 get_protocol_instructions。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_nameNo成品文件名(.html)
return_modeNo成品交付方式:base64(默认,兼容);url 推荐——返回72h下载短链(file.url),防大文件(本工具成品常达MB级)撑爆上下文,外部客户端建议默认 url
content_htmlYes完整内容HTML文档

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden: discloses 2–4MB output size, 72h download short-link default, base64 fallback, offline self-containment. Missing only info on failure modes or rate limits, but the delivery behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but efficient single paragraph front-loading the core transformation, then prerequisites and delivery mode. No wasted sentences, though multi-clause parentheses make it busy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the transformation, upstream/downstream sequencing, skill/protocol prerequisites, and delivery semantics for a 3-param, no-output-schema tool. Adequate; only missing edge-case/error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already has a description (file_name, return_mode enum with url recommendation, content_html). Description restates return_mode default but adds little beyond the schema. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: wraps content HTML into a self-contained offline HTML presentation with Plotly.js inlined. Clearly distinguishes itself from siblings like generate_dashboard/generate_word_report and names ppt_extract_data as the upstream data step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit sequence: first use ppt_extract_data, then this tool; consult get_skill_instructions(skill=ppt) for HTML structure; prerequisite get_protocol_instructions. States the recommended delivery mode (url) and its rationale. Nothing left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.