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

Overview Schema Source Related Servers Discussions Admin

ppt_extract_data

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.

Instructions

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reports": "<reports>"
    },
    "name": "ppt_extract_data"
  }
}

Input Schema

Name	Required	Description	Default
`reports`	Yes	至少1张报表txt：文件名→全文
`dimension`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A3.6/5.0

Behavior3/5

Does 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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.