Skip to main content
Glama
chang0911

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

by chang0911

generate_word_report

Create formatted Word reports for feasibility studies, economic evaluation, national economic evaluation, or general official documents, with auto-assembled appendix tables, charts, and engine-verified figures.

Instructions

Word报告双管线:report_type=gongwen(默认)=通用公文格式,标题+内容块数组;report_type=feasibility/econ=可研/经济评价报告;report_type=national=国民经济评价专项报告(10章标准目录+national_data{benefits,costs,rate}与 run_national_econ 输入同构,附表自动组装)——平台可研技能标准(正文四号字、封面、目录、11张附表自动组装、图表标准渲染;专业版60-75页/简版30-40页),传 report+charts,附表数据源三选一 p_id/files(五类输入,推荐——引擎直算标准11张全年份轴)/reports。章目录与标准硬校验(可研8章/经济评价6章,名称顺序不可改,不符拒收并返回标准目录);正文数字自动与引擎值域比对(number_audit.unmatched 清单=疑似换算/编造,须改回引擎原值);数字占位符(推荐):{{章节.键.年份}} 由系统从引擎值直灌(键名=get_chapter_data 各章 data 键,chapter=list 查清单),数字零漂移。默认返回72h下载短链(return_mode="base64" 可回退)。gongwen 模式 content_blocks 每块:标题/正文 {"type":"heading1|heading2|heading3|body","text":"..."};说明行 {"type":"info","label":"口径","value":"万元"}(或 {"type":"info","text":"..."});表格 {"type":"table","headers":["列1","列2"],"rows":[["a","b"]]}(也接受 header/columns 别名、[[表头行],[数据行]...] 整体二维数组、竖线分隔文本)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
p_idNo平台项目号(feasibility/econ 自动组装11张附表用;与 reports 二选一)
filesNo五类输入txt全文(附表推荐数据源:引擎直算标准11张全年份轴,防自拼表删全0列)
stageNo项目阶段目录,默认 scheme_stage
titleNo
chartsNofeasibility/econ 图表数据规格数组:[{key,type:pie|bar|bar_grouped|line|area|line_fill|tornado|hist_cdf,title,categories,series:[{name,values}],unit?,threshold?:{value,label},baseline?,color_mode?}]——系统按可研技能标准(Microsoft YaHei、150dpi、饼图右侧图例只显百分比)渲染PNG并插入 section.charts 引用处;数据一律取自 get_chapter_data/run_uncertainty 返回值
reportNofeasibility/econ 的报告正文 {meta:{project_name,project_stage,date,type:government|enterprise}, chapters:[{title, sections:[{title, paragraphs:[段落字符串], tables?, charts?:[key], subsections?}]}]};附表 appendix 不要自己搬——传 p_id 或 reports 由系统自动组装
add_tocNo
reportsNo11张报表数据源(fast_calc_reports 返回的 tables 整包,或 {报表文件名:原生txt}),无平台项目号的外部会话用
subtitleNo
file_nameNo
project_idNo
report_typeNo出稿管线:gongwen=通用公文格式(默认,title+content_blocks 简单块,正文三号);national=国民经济评价专项报告(10章标准目录+national_data{benefits,costs,rate}与run_national_econ输入同构,5张专项附表自动组装,契约见 get_skill_instructions(skill=national_report));feasibility=可行性研究报告——按平台可研技能标准(发改委2023大纲,正文四号字、封面、自动目录、11张E投附表全年份自动组装、图表按技能标准渲染;专业版60-75页≥300段、简版30-40页≥150段,篇幅标准与report契约见 get_skill_instructions(skill=feasibility_report));econ=经济评价报告(6章,契约见 econ_report 模板)
return_modeNo成品交付方式:默认 url——返回72h下载短链(file.url),防大文件撑爆上下文;base64 可回退
project_nameNo
project_stageNo
content_blocksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations to lean on, the description carries the full burden and does so richly: hard chapter-catalog validation that rejects non-conforming submissions and returns the standard catalog, number_audit.unmatched flagging suspected fabricated/converted figures, number placeholders that auto-fill from engine values to prevent drift, and default 72h download short-link delivery with base64 fallback. This is exactly the kind of mutation/validation/auth-adjacent behavior an agent needs.

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

Conciseness2/5

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

Nearly everything is packed into a single run-on paragraph with no line breaks or hierarchy, mixing pipelines, validation, placeholder syntax, delivery mode and block formatting. The content is mostly valuable, but the scanning cost is high and it is not front-loaded by task.

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?

For a 16-parameter, nested-object tool with no output schema and no annotations, the description covers generation modes, data sources, validation behavior, delivery format and block structure thoroughly. The main residual gap is the exact shape of the returned result object beyond the download URL, which it only gestures at.

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

Parameters4/5

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

At 50% schema coverage the description must compensate, and it adds real meaning for the complex params: the three-way data-source choice (p_id/files/reports), the report_type pipelines, the content_blocks block grammar (heading/info/table plus accepted aliases and whole 2D array form), and the charts spec with rendering standards. Trivial params (title, file_name, subtitle, project_id) remain undocumented, keeping it from a 5.

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?

States a specific verb+resource ('生成Word报告') and enumerates four distinct output pipelines (gongwen/feasibility/econ/national) with their differing contracts, so an agent can distinguish which mode it needs without opening another tool. It also implicitly separates this doc-generation tool from data-producing siblings like get_chapter_data and fast_calc_reports, which it names as data sources.

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

Usage Guidelines4/5

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

Gives clear routing: which report_type to pick, which data source to use (p_id/files is explicitly '推荐' over reports), and points to get_skill_instructions for the feasibility/econ/national contracts. It lacks explicit when-not-to-use guidance versus siblings like run_delivery_bundle or fast_calc_excel, so it stops short of full alternative coverage.

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