Convert E-Investment report text into structured JSON data for writing PPT content without manually copying figures. Select all, debt, profit, investment, cashflow, or operation dimensions.
演示文稿取数：E投报表txt → 结构化数据JSON（供撰写PPT文稿内容，不必手抄报表数字）。dimension: all|debt|profit|investment|cashflow|operation。前置：需先调 get_protocol_instructions。
| Name | Required | Description | Default |
|---|---|---|---|
| reports | Yes | 至少1张报表txt：文件名→全文 | |
| dimension | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses one important behavioral trait, the mandatory get_protocol_instructions prerequisite, but says nothing about failure modes, missing-report handling, or the shape/limits of the emitted JSON.
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?
Compact and front-loaded: the transformation is stated first, then the dimension list, then the prerequisite. The enum repetition is slightly redundant but not harmful.
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?
For a two-parameter, nested-object transform with no output schema, the description covers the input-to-output mapping, the dimension options, and the prerequisite step. It leaves the JSON output structure unspecified, a minor gap given no output schema exists.
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 50%. The reports parameter is already documented in the schema (filename→full text), and the description merely re-lists the dimension enum values that the schema already enumerates, adding no real semantic explanation of what each dimension yields.
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?
States a specific verb and resource: it converts E-investment report txt into structured JSON for PPT authoring. An agent can tell it is a data-extraction transform, distinct from sibling generators like generate_ppt_html. It stops short of explicitly naming the sibling it replaces or excludes, keeping it at 4.
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?
Gives clear context (used to avoid manually copying report figures into PPT scripts) and an explicit prerequisite: get_protocol_instructions must be called first. It does not explain when NOT to use it or which alternative to pick among the calc/generate siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.