Skip to main content
Glama

users_reset_user_traffic

Reset a user's traffic counter to zero by user ID, enabling fresh usage tracking. Requires confirm:true to execute; otherwise it returns a request preview.

Instructions

POST /api/users/{userId}/actions/reset-traffic Reset user traffic Tags: Users Controller

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userIdYes
confirmNoПодтверждение выполнения не-GET операции. Без confirm:true возвращается превью запроса (метод, URL, тело) и запрос не отправляется (см. MCP_CONFIRM).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It never says this is a destructive, likely irreversible clearing of usage counters, nor mentions permission requirements or side effects on subscription/limits — it only repeats the endpoint and verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and the action is front-loaded, but it is padded with boilerplate ('Tags: Users Controller') and a raw HTTP verb/path rather than agent-oriented prose. No sentence is actively harmful, but the structure is endpoint documentation rather than tool guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no annotations, no output schema, and only 50% parameter coverage, the definition is under-specified. An agent gets no confirmation of irreversibility, scope, or return behavior beyond the request preview implied by the confirm parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%: the confirm parameter is documented in the schema, but userId has no schema description. The description only embeds {userId} in the path template, which marginally clarifies that userId is a path parameter without adding format, range, or lookup semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Reset user traffic') and the underlying route, so the basic action is identifiable. However, it gives no differentiation from close siblings such as users_bulk_actions_bulk_reset_user_traffic or nodes_reset_node_traffic, leaving the agent to infer scope from the name alone.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus the bulk reset variants or other user-mutation tools. The only context is an HTTP route and a tag list, neither of which tells the agent which conditions select this tool.

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

Install Server

Other Tools