Skip to main content
Glama

users_bulk_revoke_subscription

Revoke subscriptions for multiple Remnawave users in bulk by numeric user IDs, with up to 500 IDs per request.

Instructions

Revoke users subscription by User IDs

Input Schema

NameRequiredDescriptionDefault
userIdsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds nothing about what revoking does (access termination, reversibility, notification, whether the subscription record is deleted) or about batch failure behavior. For a mutation that revokes subscriptions across up to 500 users, this leaves the effect semantics entirely unspecified.

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?

A single tight sentence with the verb and input front-loaded and no filler. It is efficient but so terse that it omits information the tool needs, which is an under-specification issue rather than a conciseness win.

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 bulk mutation with no output schema, no parameter descriptions, and only minimal annotations, the description should at least cover scope limits, partial-failure semantics, or reversibility. None of that is present, so an agent cannot predict the outcome of calling it.

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 0%, but there is only one parameter and the description explicitly names the input, 'User IDs', which maps to the userIds array. It adds no format constraints beyond that; the 1-500 item bounds and numeric item type come only from the schema.

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?

States a specific verb (Revoke) and resource (users' subscription) with the batch scope implied by the name and 'by User IDs' phrase, so it is distinguishable from the singular sibling users_revoke_subscription. It stops short of explicitly saying it operates on many users at once, which the name carries but the description does not reinforce.

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?

No indication of when to use this bulk variant versus users_revoke_subscription, and no prerequisites or exclusions are given. The agent must infer from the name alone that this is the multi-user form.

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