Skip to main content
Glama

users_bulk_all_update

Apply new settings to every user in one bulk operation—email, status, traffic limit, expiration, tag, and more. Runs asynchronously and returns 202.

Instructions

Update ALL users at once (async, returns 202)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoNew tag for all
emailNoNew email for all
statusNoNew status for all
expireAtNoNew expiration date for all
telegramIdNoNew Telegram ID for all
descriptionNoNew description for all
hwidDeviceLimitNoNew HWID device limit for all
trafficLimitBytesNoNew traffic limit for all
trafficLimitStrategyNoTraffic reset period for all

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

B3.4/5.0
Behavior3/5

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

The description discloses two important behavioral traits: the operation is asynchronous and returns HTTP 202. This is genuinely useful context beyond the schema. However, with no annotations provided, the description carries the full burden of behavioral disclosure, and it does not mention that all parameters are optional (so an empty call is valid), whether the operation is destructive/irreversible, or what the async response means for the agent (e.g., no immediate result, need to poll). The async disclosure is good but incomplete for a bulk mutation with zero annotation coverage.

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

Conciseness4/5

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

The description is a single compact sentence that front-loads the key facts: scope ('ALL users'), operation ('Update'), and behavior ('async, returns 202'). Every word earns its place. It could be slightly more structured (e.g., separating the async note), but it is appropriately sized and immediately scannable.

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

Completeness3/5

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

For a bulk mutation tool with 9 optional parameters, no annotations, and no output schema, the description is minimally adequate but leaves gaps. It tells the agent the call is async and returns 202, but does not explain what happens after the 202 (e.g., is there a job to poll?), whether an empty body is allowed, or how this differs from users_bulk_all_reset_traffic and users_bulk_all_extend_expiration. The schema covers parameters, but the operational context is incomplete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 9 parameters with per-field descriptions. The description adds no parameter-level meaning beyond the schema, which is the baseline 3 case. It does not clarify semantics like whether fields are applied only if provided, or how the enum values interact, but the schema already covers the basic meaning of each field.

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

Purpose4/5

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

The description states a specific verb ('Update') and resource ('ALL users'), and notes it is async and returns 202. This clearly distinguishes it from single-user update tools like users_update and from bulk operations that target a subset (users_bulk_update). It loses one point because it doesn't explicitly name the sibling it is not, though the 'ALL' emphasis and async note do most of the differentiation work.

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

Usage Guidelines3/5

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

The description implies this is for updating every user at once, which is a clear context signal. However, it does not explicitly state when to prefer this over users_bulk_update, users_bulk_all_reset_traffic, or users_bulk_all_extend_expiration, nor does it mention any prerequisites or caveats (e.g., no required parameters means it can be called with an empty body, which is a notable behavior). The async/202 note hints at usage but doesn't provide explicit when/when-not guidance.

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

Deploy Server

Other Tools