Skip to main content
Glama

user_otp_delete

Disable OTP authentication for a user account via DELETE request. Optionally act on behalf of another user as admin.

Instructions

DELETE /user/otp Отключение OTP Тег: OTP Спека: user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesquery параметр "token"
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.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 behavioral burden. It only implies destruction by echoing the DELETE route and 'disabling OTP'; it says nothing about auth/permission requirements, irreversibility, what happens to existing OTP state, or the fact that the operation is gated behind a preview/confirm flow (that only appears in the schema's confirm field).

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

Conciseness2/5

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

It is short, but the space is spent poorly: the first line duplicates the tool name as an HTTP route, and 'Тег: OTP' / 'Спека: user' are generator metadata that do not help an agent. The useful fact (this disables OTP) is not front-loaded and is buried behind the redundant route line.

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?

This is a mutation (OTP disabling) with no annotations, no output schema, and a confirm-gated execution model. The description omits every behavioral detail an agent needs before calling it, leaving the schema's confirm field to do work the description should have surfaced.

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%: token, confirm (preview vs. real execution), and user_id (admin acting on behalf of a user) are all documented in the schema. The description adds no parameter meaning of its own, so the baseline of 3 applies.

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

Purpose3/5

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

The description states a route (DELETE /user/otp) and, in Russian, the action ('Отключение OTP' = disabling OTP), so an agent can identify verb and resource and distinguish it from user_otp_setup_post / user_otp_get / user_otp_post. However, the primary line merely restates the tool name as a raw HTTP route, and the meaningful content is in a different language than the rest of the tool surface, weakening immediate clarity.

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 guidance on when to use this versus alternatives, no prerequisites, and no exclusions. Siblings like user_otp_setup_post, user_otp_get, and user_otp_put clearly overlap the OTP domain, yet the description does not route between them.

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