评价产品
rate_product登录;给某产品打 1–5 星 + 可选文字评价(一人一产品一条,再次调用即编辑)。不能评价自己的产品。先用 get_product/search_products 拿 productId。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | 文字评价,可选 | |
| score | Yes | 星级 1–5 | |
| productId | Yes | 产品 id |
rate_product登录;给某产品打 1–5 星 + 可选文字评价(一人一产品一条,再次调用即编辑)。不能评价自己的产品。先用 get_product/search_products 拿 productId。
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | 文字评价,可选 | |
| score | Yes | 星级 1–5 | |
| productId | Yes | 产品 id |
Changes observed during successful MCP inspections.
Input schema / properties / body / descriptionPrevious value: -"文字评价,可选"New value: +"文字评价,可选"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare idempotentHint and non-destructive, so the description carries most of the burden and does so well: it discloses the login requirement, the upsert/edit-on-repeat semantics, and the business rule forbidding self-rating. These are behaviors no structured field in the definition conveys, and none contradict the annotations.
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 compact clauses with zero filler: auth, action, uniqueness/upsert rule, self-rating exclusion, and the prerequisite lookup. The prerequisite is placed last but the mutating action is front-loaded, so an agent skimming the first clause already knows the operation.
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 simple three-parameter write tool with no output schema, the description covers everything needed to invoke it correctly: auth, ID sourcing, argument meaning, cardinality, and the self-rating restriction. Nothing material is left to inference.
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 100% and the schema already documents productId, score (min/max 1–5) and optional body. The description's mention of the 1–5 star range and optional text merely restates the schema rather than adding format or sourcing detail beyond 'get productId from get_product/search_products'.
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 states a specific verb and resource ('给某产品打 1–5 星 + 可选文字评价') and immediately scopes the operation with the one-per-user-per-product upsert rule. An agent can distinguish this from adjacent tools like get_product_ratings or delete_my_rating without inspecting any schema.
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?
It gives an explicit authentication prerequisite ('登录'), a concrete discovery step ('先用 get_product/search_products 拿 productId'), and an exclusion ('不能评价自己的产品'). It also clarifies the repeat-call behavior, so an agent knows it does not need a separate edit tool.
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.