Skip to main content
Glama
uk-kd

operbots-mcp

by uk-kd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Изменить данные аккаунта

account_update

Update a team member's profile: name, birth date, phone, timezone, Telegram/MAX IDs, changing only submitted fields. Complete missing last name, first name, and birth date to unlock the API.

Instructions

Меняет ФИО, дату рождения, телефон, часовой пояс и номера в Telegram и MAX учётной записи — по номерам бот шлёт участнику весточки из сценария (узел «Сообщить в чат» с адресатом «участник команды»). Передавайте только те поля, которые нужно изменить: остальные останутся как есть. Этим же инструментом проходят шаг знакомства: пока фамилии, имени и даты рождения нет, API закрыт целиком.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
phoneNoТелефон.
max_idNoНомер человека в MAX. null — стереть.
timezoneNoЧасовой пояс, например Europe/Moscow.
last_nameNoФамилия.
birth_dateNoДата рождения в виде ГГГГ-ММ-ДД. Без неё профиль считается незаполненным.
first_nameNoИмя.
middle_nameNoОтчество.
telegram_idNoНомер в Telegram (число, не @имя). null — стереть.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.17
    • addedInput schema / properties / max_id
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Номер человека в MAX. null — стереть."
+}
    • addedInput schema / properties / telegram_id
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Номер в Telegram (число, не @имя). null — стереть."
+}
  2. Changed1 schema field changedv0.1.14
    • addedInput schema / properties / birth_date
      Added value: +{
+  "description": "Дата рождения в виде ГГГГ-ММ-ДД. Без неё профиль считается незаполненным.",
+  "type": "string"
+}
  3. First observedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

Annotations only say readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds meaningful behavioral context: partial-update semantics, the onboarding gating condition ('пока фамилии, имени и даты рождения нет, API закрыт целиком'), and the role of Telegram/MAX numbers in sending scenario messages. This goes beyond the annotations without contradicting them.

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

Conciseness4/5

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

The description is compact and front-loaded with the main action and affected fields. Each sentence adds either scope, update semantics, or a critical usage condition. The first sentence is somewhat dense with the parenthetical about scenario messages, but nothing is redundant.

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?

Given 8 optional parameters, no output schema, and minimal annotations, the description covers the most important call semantics: which fields can be changed, how to do partial updates, and when the API is unavailable. It does not describe return values or permissions, but those are less critical for an update tool with this level of schema documentation.

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?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds important cross-parameter guidance such as 'Передавайте только те поля, которые нужно изменить' and the fact that the API stays closed until name and birth date are present. This helps an agent understand that omitting fields is intentional and does not clear them.

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 uses a specific verb and resource: 'Меняет ФИО, дату рождения, телефон, часовой пояс и номера в Telegram и MAX учётной записи', which clearly identifies what the tool does. It does not explicitly contrast with sibling tools like members_save or dialogs_update, but the field list and 'учётной записи' scope make the purpose reasonably unambiguous.

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

Usage Guidelines4/5

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

The description gives clear usage context: 'Передавайте только те поля, которые нужно изменить: остальные останутся как есть' explains partial updates, and 'Этим же инструментом проходят шаг знакомства' identifies a key scenario. It does not explicitly say when not to use this tool or name alternatives, so it stops short of a 5.

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