Bulk reset traffic for up to 500 users by providing their user IDs in a single request.
POST /api/users/bulk/reset-traffic Bulk reset traffic users by User IDs Tags: Users Bulk Actions Controller
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| confirm | No | Подтверждение выполнения не-GET операции. Без confirm:true возвращается превью запроса (метод, URL, тело) и запрос не отправляется (см. MCP_CONFIRM). |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys only the method and endpoint; it says nothing about whether resetting traffic is reversible, whether it is destructive, rate limits, or side effects on subscription counters. The only behavioral hint comes from the schema's confirm parameter, not the description.
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?
The description is two filler lines: a raw path and a 'Tags:' line that is pure OpenAPI scaffolding with no value to an agent. The single informative clause is buried after the URL. It is short but not front-loaded with useful information.
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 mutating bulk operation with no annotations and no output schema, the definition is under-specified. It omits max-batch behavior (maxItems 500), the confirmation-based preview mechanism described in the schema, and any indication of what the call returns or alters.
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 50% (the confirm parameter is documented in the schema; the nested body.userIds array with maxItems 500 is not). The description adds nothing about parameter meaning beyond restating 'by User IDs'. With one of two parameters documented and the nested structure undocumented, this lands at the baseline rather than compensating for the gap.
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 verb and resource ('Bulk reset traffic users by User IDs') plus the raw HTTP route, which identifies the operation. However it is largely a restatement of the tool name and title, and the phrasing 'Bulk reset traffic users' is awkward. It does not differentiate itself from sibling users_reset_user_traffic or users_bulk_actions_bulk_all_reset_user_traffic beyond the implied 'by IDs' scope.
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?
No when-to-use or when-not-to-use guidance. The 'by User IDs' phrase implicitly distinguishes it from the 'all users' variant, but the description never names alternatives or states prerequisites. Siblings like users_reset_user_traffic (single) and bulk_all_reset_user_traffic (everyone) are not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.