Activate user

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

Annotations already mark this as a non-read-only, non-destructive operation. The description states the concrete effect ('status to active') but adds no further behavioral context such as idempotency, effect on subscription data, or failure conditions. There is no contradiction with the annotations.

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

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

One short, front-loaded sentence with no filler. Every word contributes to communicating the tool's purpose, and the description is an model of concise structure.

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

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

For a one-parameter state-transition tool with an output schema and basic annotations, the description is mostly sufficient: the target and action are clear. It omits optional behavioral details such as idempotency or interaction with deactivated/held states, but these are not required for a correct call.

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

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

The schema provides only the username property name and constraints, with no parameter description, and the tool description does not explicitly explain the username parameter's role. Still, the phrase 'a user's status' implicitly ties to the single username parameter, so the meaning is recoverable even though the description adds little beyond the schema.

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

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

The description uses a specific verb ('Sets') and a concrete resource/outcome ('a user's status to active'), clearly distinguishing it from the sibling marzban_users_deactivate and marzban_users_hold tools. It is not a tautology and names the exact state transition.

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

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

No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. However, the action word 'activate' and the sibling set make the intended context reasonably inferable, which is the boundary between 'implied use' and 'no guidance'.

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