Skip to main content
Glama

users_extend_expiration

Extend a Remnawave user's expiration date by a set number of days, reactivating expired users while preserving disabled or limited status.

Instructions

Extend user expiration date. If user status is EXPIRED, the new expiration date is calculated from the current date and the user becomes ACTIVE. If user status is ACTIVE, the given number of days is added to the existing expiration date. DISABLED and LIMITED users will be extended, but their status will not change.

Input Schema

NameRequiredDescriptionDefault
daysYesThe number of days to extend the expiration date.
userIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

A4.1/5.0
Behavior5/5

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

The description goes well beyond the annotations by fully specifying the state-dependent outcome: EXPIRED users get a new date from the current date and become ACTIVE, ACTIVE users get days added to the existing date, and DISABLED/LIMITED users are extended without a status change. This is exactly the mutation semantics an agent needs and cannot derive from readOnlyHint=false/destructiveHint=false.

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?

The core action is front-loaded, followed by three tightly packed conditional clauses, each covering a distinct user status with zero filler. Every sentence carries behavioral information.

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

Completeness4/5

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

For a state-mutating tool with no output schema, the description covers the critical per-status outcomes thoroughly. The only material gap is the absence of routing context relative to the bulk expiration tools, which would help correct tool selection.

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

Parameters4/5

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

The schema documents 'days' (50% coverage) but leaves userId unexplained. The description compensates by clarifying the meaning of 'days' conditionally — relative to the current date for EXPIRED users versus added to the existing date for ACTIVE users — which is semantic value beyond the schema's generic 'number of days to extend'.

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+resource ('Extend user expiration date') that clearly names what the tool does. The singular 'user' implicitly distinguishes it from the bulk siblings (users_bulk_extend_expiration), but it never names those alternatives explicitly, so differentiation is only inferred.

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 only implied: the agent can infer this applies to a single user, but there is no explicit when-to-use guidance, no exclusion of the bulk variants, and no stated prerequisites (e.g., which user states can be extended is covered, but not when to choose this over users_bulk_extend_expiration).

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