Skip to main content
Glama

user_passwd_reset_verify_post

Verifies a password reset token to update a user's password. Submits the token and encrypted new password to complete the reset process.

Instructions

POST /user/passwd/reset/verify Сменить пароль пользователя по токену сброса Тег: Пользователи Спека: user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoТело запроса (application/json)
confirmNoЯвное подтверждение выполнения не-GET операции. Без confirm:true в режиме rw возвращается превью запроса.
user_idNoadmin acts on behalf of this user

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/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 behavioral burden and it does not meet it. It never states that the call mutates credentials irreversibly, whether authentication or a valid token is required, or that non-GET operations return a preview unless confirm:true is set (a fact only the schema reveals).

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

Conciseness3/5

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

It is short and front-loaded with the route and action, but the 'Тег: Пользователи / Спека: user' lines are generator metadata that consume space without helping an agent invoke the tool.

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 credential-mutating POST with no annotations and no output schema, the description should at minimum describe the token-flow context and required confirmation. It leaves both the workflow position and the safety profile entirely to the schema and the agent's inference.

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 the confirm preview behavior, the admin acting-as semantics of user_id, and that password must be encrypted. The description adds nothing beyond this, which is the expected baseline when the schema does the heavy lifting.

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 and resource ('Сменить пароль пользователя по токену сброса') plus the underlying HTTP route, so an agent knows this completes a password reset using a token. However, it gives no differentiation from the closely named siblings user_passwd_reset_post, user_passwd_reset_verify_get, user_passwd_post and admin_user_passwd_post, so it cannot be told apart from them on description alone.

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?

There is no when-to-use guidance: nothing says whether this is the step that must follow user_passwd_reset_post, or how it relates to the GET variant user_passwd_reset_verify_get. The only routing hint is the tag/spec metadata, which does not help select between alternatives.

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

Install Server

Other Tools