删除我的评价
delete_my_rating登录;删除当前用户对某对象(产品/园区/主理人)的评价(幂等:没有则 no-op)。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | 目标对象 id | |
| targetType | Yes | PRODUCT 产品 | PARK 园区 | USER 主理人 |
delete_my_rating登录;删除当前用户对某对象(产品/园区/主理人)的评价(幂等:没有则 no-op)。
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | 目标对象 id | |
| targetType | Yes | PRODUCT 产品 | PARK 园区 | USER 主理人 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry idempotentHint=true, so the description does real work: it adds an authentication requirement and explains what idempotency means here ('no-op if no rating exists'), which is genuinely beyond the raw annotation flag. It stops short of stating permanence/reversibility or whether aggregate rating summaries are recalculated.
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?
A single compact sentence with the action, target types, auth precondition, and idempotency note—no filler. Minor weakness: it leads with the '登录' precondition rather than the action, and the semicolon/parenthesis stacking makes it slightly dense.
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-required-parameter mutation with no output schema, the description covers authentication, the target universe, and the empty-case behavior, which is enough to call it correctly. It could add one clause about effect (e.g., that the underlying rating record and any aggregate score are removed) but nothing essential is missing.
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 100% and both required parameters already describe targetId and the PRODUCT/PARK/USER enum with their Chinese meanings. The parenthetical '(产品/园区/主理人)' merely mirrors the schema enum descriptions, adding no syntax, format, or edge-case semantics beyond it, so baseline 3 applies.
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 (delete) and a specific resource (the current user's own rating of a target), plus the scope restriction that only 'my' rating is affected and the three target types. It is clearly distinguishable from rate_product and get_product_ratings, though it doesn't name any of those siblings explicitly.
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?
The '登录' prefix establishes a precondition (must be authenticated), and the verb implies usage, but there is no explicit when-to-use / when-not-to-use guidance and no pointer to alternatives such as rate_product for updating vs. deleting a rating. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.