Initiates a points transfer, deducting the fee from the amount for internal mode or charging it separately for external mode; set confirm to true to execute after authorization.
发起积分转账；internal 从金额内扣手续费，external 额外扣手续费。当前前端限制单笔 2–20。confirm=true 执行。
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| address | Yes | ||
| confirm | No | 确认用户已授权此次操作后设为 true | |
| fee_mode | No | internal |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: the fee is deducted from the amount for internal vs. charged on top for external, and execution is gated on confirm=true. It does not say what happens when confirm is false (preview, validation-only, or nothing), which is the main remaining gap.
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?
Four short clauses, front-loaded with the action, then fee semantics, then the confirm rule. The '2–20' clause duplicates the schema's minimum/maximum and is the one piece that does not earn its place.
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?
An output schema exists, so return values need not be described. However, for a destructive, irreversible points transfer, the description omits what confirm=false actually does, whether the transfer can be undone, and what the address refers to, which an agent needs to invoke it safely.
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 description coverage is only 25%, so the description must carry the load. It does explain fee_mode's two enum values behaviorally and clarifies the confirm gate, but 'address' (the recipient identifier) is completely undocumented in both schema and description, leaving one of four parameters blind.
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?
The description opens with a specific verb+resource ('发起积分转账' — initiate a points transfer), which contrasts clearly with sibling reads such as share_list_point_transfer_records and share_get_point_transfer_quota. It never names a sibling or states which it is not, so it stops short of a 5.
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?
'confirm=true 执行' gives one concrete execution precondition, which is useful, but there is no guidance on when to pick internal vs external fee_mode or how this differs from share_handle_point_transfer. Usage is only implied from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.