传承·交大 MCP

Overview Schema Source Related Servers Discussions Admin

share_redeem_points

Destructive

Redeem points from supported partner sites into Chuancheng points by specifying the source and amount; set confirm=true to execute the exchange.

Instructions

消耗合作站点积分换传承积分；amount 为来源积分数量，到账以平台为准。confirm=true 执行。

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": {
      "source": "<source>",
      "amount": "<amount>"
    },
    "name": "share_redeem_points"
  }
}

Input Schema

Name	Required	Description
`amount`	Yes
`source`	Yes
`confirm`	No	确认用户已授权此次操作后设为 true

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already flag destructive=true and openWorld=true; the description adds real value by disclosing the two-step confirm gate ('confirm=true 执行') and that credited amounts are uncertain ('到账以平台为准'). It doesn't state reversibility or failure handling, but the confirm mechanism is the key behavioral fact.

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?

Two compact clauses with no filler; the exchange semantics and the confirm requirement are both front-loaded. Slightly dense punctuation-separated clauses rather than full sentences, but nothing wasteful.

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 destructive, open-world mutation with an output schema available, the description covers the essential facts an agent needs: it spends external points, the credited amount is platform-determined, and confirmation is required. The unexplained source enum is the only notable gap.

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 33% – only confirm is documented in the schema. The description compensates for amount by defining it as the source-points quantity and clarifies that confirm=true triggers execution, but the source enum values (shuiyuan/sjtuplus/sjtuwiki) and their meaning are never explained in prose.

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: consuming partner-site points to exchange for platform (inheritance) points. An agent can distinguish it from read-only siblings like share_get_redeem_quota or share_list_redeem_records, though it doesn't name them explicitly.

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

Usage Guidelines3/5

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

Usage is implied by '消耗…换…' (consume to exchange) and the confirm=true gate, but the description never says when to prefer this over the quota/records siblings or what preconditions (e.g., sufficient balance, quota check first) apply.

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

Deploy Server