Skip to main content
Glama
Sign In
mcp-remnawave

mcp-remnawave

by Nurullaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

users_bulk_delete_by_status

Delete all users with a specific status in one operation. Choose from active, disabled, limited, or expired accounts to clean up your user list.

Instructions

Bulk delete users by status

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "status": "<status>"
    },
    "name": "users_bulk_delete_by_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusYesUser status to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

B3.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 burden. It reveals that the tool deletes users (destructive) but does not state permanence, side effects, scope confirmation, or whether it is a hard or soft delete. For a bulk destructive operation, this lack of behavioral disclosure is a significant gap.

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

Conciseness5/5

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

Five words convey the verb, resource, and filter with no filler. The key qualifier ('by status') is front-loaded. Perfectly concise for what it states.

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?

With no output schema slash annotations and a destructive bulk operation, the description is too thin. An agent is missing information about irreversibility, affected scope, waiting behavior, and potential confirmation steps. The single well-documented parameter does not compensate for the missing operational context.

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% and the schema explicitly defines status as 'User status to delete'. The description adds no further parameter semantics but also doesn't need to given the schema fully documents the parameter. Baseline applies.

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

Purpose5/5

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

States a specific verb (delete), resource (users), and scope (bulk by status). The 'by status' qualifier distinguishes it from users_bulk_delete (presumably by IDs) and users_delete (single). Clear and unambiguous.

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?

Usage is implied through 'delete users by status' – if an agent needs to remove multiple users sharing a status, this is the tool. However, no explicit alternatives or exclusions are mentioned, and no guidance on when not to use it, though the operation type makes the use case reasonably inferable.

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