Create surveys and quizzes, collect and analyze responses, and generate reports with WebAsk through 161 MCP tools.
Scored across 162 tools
Most tools target distinct actions, but there are overlapping clusters that will confuse selection: get_quiz_crm_fields vs manage_quiz_crm vs manage_quiz_crm_mapping vs manage_quiz_amocrm_mapping, get_quiz_hidden_options vs get_quiz_widgets_hidden, and the four near-identical export_answers_* tools. Descriptions do help disambiguate in most cases, but at 162 tools the boundaries are frequently fuzzy.
Names are uniformly snake_case and mostly follow verb_noun, which aids readability. However, verb prefixes are inconsistent for similar operations (save_ vs update_ vs manage_ vs set_ vs toggle_ vs make_), and ambiguous multi-purpose verbs like 'manage_' and 'get_' cover several different operations each.
162 tools is an extreme mismatch for any single server scope, far beyond the 3-15 range and well past the 25+ threshold. Even a broad survey platform does not need this many separate tools; many are thin wrappers that could be parameterized.
Coverage is remarkably broad: quizzes, widgets, logic, themes, webhooks, integrations, workspaces, members, roles, scheduling, promo codes, and reporting all have read/write/delete paths. Gaps exist (payments, domain wiring, member invites via UI only) but most are deliberate safety boundaries rather than missing lifecycle operations.
Добавляет новые промокоды в существующий список.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | Массив строковых кодов для добавления (до 1000, каждый max 250 символов). | |
| list_id | Yes | ID списка промокодов. Взять из promocode://list. | |
| quiz_id | Yes | ID опроса в нужном workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds that it appends new codes to an existing list, which is consistent but adds little beyond the annotations. No contradiction.
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?
A single, front-loaded sentence that communicates the core action without any wasted words.
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?
Given full schema descriptions, safety annotations, and no output schema, the description plus structured fields are largely sufficient for correct invocation. Minor gaps remain around duplicate handling and side effects, but these are not critical for selecting and calling the tool.
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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level semantics beyond what the schema provides.
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?
States a specific verb ('Добавляет') and resource ('новые промокоды') scoped to an existing list, so the action is clear. However, it does not differentiate from sibling tools like create_promocode_group or manage_promocode_group, leaving the agent to infer uniqueness.
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?
Provides no when-to-use guidance, no prerequisites, and no alternatives or exclusions. The only implied condition is that the target list already exists, but this is not stated as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавляет адрес для уведомлений автору. Сразу он не работает: на адрес уходит письмо с кодом, и пока человек его не подтвердит, туда ничего не отправляется. Число адресов ограничено тарифом.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Адрес, на который слать уведомления о новых ответах. | ||
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag it as non-read-only, non-idempotent, open-world. The description adds genuinely useful behavior: the address is inert until a code is confirmed by email, and the number of addresses is capped by the tariff. It stops short of saying what happens on a duplicate address or a quota-exceeded failure.
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?
Three short sentences, front-loaded with the action and then the two most important caveats (pending confirmation, tariff cap). No filler, though the middle sentence could be tighter.
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 two-parameter mutation with no output schema, the description covers the essential lifecycle (pending until confirmed) and a real constraint (tariff limit). It lacks error/duplicate handling, but the core information an agent needs is present.
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?
Schema description coverage is 100%, so both quiz_id and email are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.
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 states a specific verb+resource: adding an email address that receives notification copies for the quiz author. It implicitly differentiates from siblings like confirm_quiz_email_recipient and toggle_quiz_email_recipient by describing the add step of the lifecycle, though it never names them outright.
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?
Usage context is implied (you add an address when you want the author to be notified), but there is no explicit 'use this instead of X' routing and no mention of the sibling confirm_quiz_email_recipient tool that must be called next. The confirmation requirement is described as behavior, not as a usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Применяет указанную тему оформления к опросу. В ответе возвращает поле quiz с детальной информацией об опросе после применения темы: id, name, url_shared, answer_count, widgets (структура виджетов), hidden_options, folder, created_at, updated_at. Эти данные можно использовать сразу без отдельного чтения quiz://{id}/structure.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| theme_id | Yes | ID темы. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). Beyond that, the description adds substantive behavioral context: it enumerates the returned quiz payload and even notes a workflow shortcut (no separate quiz://{id}/structure read needed). It omits auth/permission requirements, but with annotations covering safety this is a genuinely additive description.
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?
Two sentences, purpose front-loaded, followed by the return-shape detail. The field list is long but justified because no output schema exists; minimal waste overall.
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 mutation tool with no output schema, the description helpfully compensates by documenting the response payload and the workflow benefit. It stops short of describing reversibility or permission requirements, but with annotations present it is complete enough to call correctly.
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?
Schema description coverage is 100% and both required params (quiz_id, theme_id) are documented in the schema itself. The description adds no format or constraint detail beyond that, so the baseline of 3 applies.
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?
States a specific verb+resource: applies a given design theme to a quiz ('Применяет указанную тему оформления к опросу'), which is clearly distinct from create_theme/update_theme/manage_theme in the sibling list. An agent can identify the operation without opening the schema.
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?
The description implies the use case (attaching an existing theme to a quiz) but gives no explicit when-to-use/when-not guidance, no prerequisites, and no named alternatives such as update_theme. Usage is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Архивирует или разархивирует опрос.
| Name | Required | Description | Default |
|---|---|---|---|
| archive | Yes | true — в архив, false — из архива. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is carried by structured data, not the description. The description adds nothing behavioral: no statement of what archiving does to the quiz (visibility, respondent access, reversibility), though the description does confirm the two-way toggle semantics. Note idempotentHint=false is questionable for a set-to-state toggle, but the description neither confirms nor contradicts it.
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?
A single short sentence with no filler, front-loaded with the verb and resource. Efficient, but its brevity is partly under-specification rather than deliberate economy.
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?
With only two fully-documented parameters and no output schema, the structured data is largely sufficient for invocation. What is missing is outcome context: whether archiving hides the quiz from listings, affects respondents, or can be undone. Adequate but not complete for a mutation tool.
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?
Schema description coverage is 100%, and both parameters carry inline descriptions ('true — в архив, false — из архива', 'ID опроса'). The description mirrors that same archive/unarchive meaning but adds no format, constraint, or edge-case detail beyond the schema. Baseline 3 is correct 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('архивирует или разархивирует опрос'), clearly distinguishing it as a state toggle rather than a create/delete/rename operation. However, it never names the sibling tools it differs from (delete_quiz, restore_quiz, publish_quiz), so an agent must infer the boundaries itself.
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?
There is no when-to-use guidance, no exclusions, and no mention of alternatives such as delete_quiz or restore_quiz. The agent learns what the tool does but nothing about when this is the correct choice over its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Подтверждает адрес получателя копий ответов кодом из письма. Пока адрес не подтверждён, он писем не получает вовсе — add_quiz_email_recipient только заводит его. Код приходит на сам адрес, прочитать его ассистент не может: попросите человека продиктовать. Попыток ограниченное число, поэтому есть и повторная отправка кода.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: confirm — подтвердить кодом, resend_code — выслать код заново. | |
| quiz_id | Yes | ID опроса. | |
| email_id | Yes | ID адреса из get_quiz_email_settings. | |
| confirmation_code | No | Код из письма. Нужен для confirm. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that the address receives no mail until confirmation, that the code is delivered to an external mailbox the assistant cannot read and must be dictated by a human, and that attempts are limited (hence resend). These are real operational constraints (rate limits, human-in-the-loop, external dependency) that annotations alone do not convey.
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?
Purpose is front-loaded in the first sentence and the following sentences each add substantive context (dependency, human step, attempt limit). Slightly dense but every sentence earns its place; no filler.
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?
No output schema exists, so the description carries the explanatory burden for a non-idempotent, open-world mutation tool. It covers the key behavior (confirmation gating, code source, resend), but does not describe what a successful confirmation returns or what state changes afterward.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by telling the agent where confirmation_code comes from (the email, dictated by the person) and why the resend path exists, which helps invoke the tool correctly.
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?
States a specific verb+resource (подтверждает адрес получателя копий ответов) and adds the second capability (повторная отправка кода), so the agent knows this tool both confirms and resends. It explicitly distinguishes itself from the sibling add_quiz_email_recipient by noting that one only registers the address.
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?
Explains the condition that makes this tool necessary: until confirmed the address receives no email at all, and add_quiz_email_recipient merely creates it. The triggers for each mode (confirm vs resend) are implied by the code and attempt-limit context. No explicit when-not guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт тег ответов в аккаунте. Тег с таким же именем не дублируется — вернётся существующий.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название тега, до 255 символов. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the get-or-create/dedup semantics, which is real behavioral value beyond the annotations. But that claim sits in tension with the supplied idempotentHint=false: a call repeated with the same workspace_id and name provably yields the same existing tag, i.e. no additional effect, so the two structured/descriptive sources disagree. The contradiction concerns a soft hint rather than safety (destructiveHint=false and readOnlyHint=false are consistent with a create), so this is not the maximum severity, but it is a genuine conflict.
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?
Two short sentences, no filler, with the core action front-loaded and the dedup caveat immediately after. Every sentence carries information.
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 simple two-parameter create tool with no output schema, the description covers the action, the account scoping, and the return behavior when the name already exists ('вернётся существующий'). Only a fuller account of the response payload or required permissions is missing, which is minor here.
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?
Schema description coverage is 100%, so both parameters (name, workspace_id) are already fully documented in the schema, including the 255-character limit and the workspace://list source. The description adds nothing about parameters, so baseline 3 applies.
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?
States a specific verb and resource ('Создаёт тег ответов в аккаунте'), which cleanly separates it from the read/assign/delete siblings such as get_answer_tags, tag_answer and delete_answer_tag. It does not name an alternative explicitly, but the operation itself is unambiguous.
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?
There is no explicit when-to-use/when-not statement or comparison with siblings like tag_answer. However, the get-or-create clause ('Тег с таким же именем не дублируется — вернётся существующий') implicitly tells the agent it can call this without first checking for existence, which is useful implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Закрывает промежуток для записи — отпуск, занятое окно, выходной. Уже сделанные записи он не отменяет. Границы задаются в UTC: часовой пояс расписания и пояс респондента различаются, и UTC — единственный способ не промахнуться.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Почему время закрыто. | |
| end_utc | Yes | Конец закрытого промежутка в UTC. | |
| start_utc | Yes | Начало закрытого промежутка в UTC, например 2026-10-01T09:00:00Z. Время без пояса тоже считается UTC. | |
| scheduler_id | Yes | ID расписания (из get_schedulers). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and non-idempotent, but the description adds a genuinely useful non-obvious trait: existing bookings in the block are not cancelled. It also warns that boundaries must be UTC, a real operational constraint.
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?
Three tight sentences with no filler; the core action is stated first, followed by the non-cancellation caveat and the UTC requirement in priority order. Slightly dense but every sentence earns its place.
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 mutation tool with safety annotations and no output schema, the description covers the essentials: what it closes, that existing bookings survive, and the timezone contract. Nothing critical is missing, though a hint on what happens with overlapping blocks would round it out.
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?
Schema description coverage is 100%, so all five parameters are already documented, including the UTC example format. The description reinforces why UTC is required (schedule vs. respondent timezone drift) but adds no new syntax or constraints, so baseline 3 is appropriate.
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?
States a specific verb+resource — closing a time interval for bookings — and enumerates concrete cases (vacation, busy window, day off). It is clearly distinguishable from delete_booking_block and update_booking, though it does not name any sibling explicitly.
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?
Gives concrete use cases (vacation, busy window, day off), which implies when to reach for it, but offers no explicit when-not guidance or named alternatives (e.g., delete_booking_block to undo). Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает новую папку для группировки опросов в выбранном workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название папки (max 255 символов). | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile of this mutation is carried by structured data. The description adds only the purpose (survey grouping), and with idempotentHint=false it does not warn that repeated calls create duplicate folders or mention required permissions, which would have been useful added context.
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?
A single front-loaded sentence with the verb, the resource, and the scope in order. No redundant or filler text.
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?
There is no output schema, so the description is the only place to state what comes back (e.g. the new folder ID needed for later moves or access management), and it does not. For a simple two-parameter creation tool with full schema descriptions and complete annotations, this is adequate but leaves a practical gap about follow-up usage.
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?
Schema description coverage is 100% and the schema descriptions are genuinely useful ('max 255 символов', 'Взять из workspace://list'), so the schema carries parameter meaning fully. The description adds nothing about parameters, making the baseline 3 appropriate.
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 states a specific verb and resource ('Создает новую папку') and adds the scope ('для группировки опросов в выбранном workspace'), so an agent can distinguish it from the many create_* siblings. It does not explicitly name the closest relatives (manage_workspace_folder, get_folder_list), so sibling differentiation is implicit rather than stated.
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?
There is no statement of when to use this tool versus alternatives such as manage_workspace_folder or get_folder_list, nor any prerequisites or exclusions. The only usage signal is 'в выбранном workspace', which just restates that a workspace must be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает новый список промокодов для workspace опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название списка промокодов (max 255 символов). | |
| codes | Yes | Массив строковых кодов для добавления в список (до 1000, каждый max 250 символов). | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that, such as duplicate handling, permission requirements, or error behavior. It only restates the creation action.
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?
A single short sentence with zero waste, front-loading the action and resource. However, it is arguably too terse for a mutation tool, but the structure itself is efficient.
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 creation tool with three required parameters and no output schema, the description is very thin. It does not explain what happens on success, whether the list is immediately usable, or any constraints beyond what the schema provides. The agent lacks sufficient context to confidently invoke it.
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?
Schema description coverage is 100%, so the schema already documents all three parameters with constraints (name max 255, codes max 1000 each max 250). The description adds no additional meaning or format details for the parameters, so the baseline of 3 applies.
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?
States a specific verb 'Создает' (creates) and resource 'новый список промокодов' (new promocode list), plus the scope 'для workspace опроса'. It does not differentiate from siblings like add_promocodes or manage_promocode_group, but the core purpose is clear.
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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it relates to add_promocodes or manage_promocode_group. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает новый опрос в указанной папке.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Название опроса (необязательно). | |
| ai_type | No | Что собирать при AI-генерации: quiz — обычный опрос, у вопросов нет правильных ответов; test — тест, где у вариантов проставлены баллы и отмечены правильные ответы, а респондент в конце получает результат. По умолчанию quiz. | |
| project | No | Метка проекта для своего учёта: произвольная строка, которая просто сохраняется у опроса. На поведение опроса не влияет, респондент её не видит. Не просите её у человека сами. | |
| folder_id | Yes | ID папки, в которой нужно создать опрос. Взять из folder://list. | |
| with_logic | No | Просить ли AI сразу построить логику переходов между вопросами (ветвление по ответам). Без неё вопросы идут подряд. Используется при AI-генерации. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so a lower bar applies. The description adds only the folder scoping constraint, but does not clarify side effects, authentication needs, defaults, or how AI generation parameters affect behavior. It does not contradict 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?
The description is a single front-loaded sentence with no wasted words. It states the action and the location constraint immediately. There is no structural issue.
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?
Given the tool's complexity, with five parameters including AI-generation options and many creation-related siblings, the description is too sparse. It does not explain when to choose this over generate_ai_quiz, create_quiz_from_template, or duplicate_quiz. Although schema and annotations cover structured details, the description does not provide enough context for correct tool selection.
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?
Schema description coverage is 100%, so the schema already documents all five parameters in detail. The description mentions only the folder context, adding no extra meaning beyond what the schema provides. The baseline of 3 applies 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: creating a new quiz, and adds the scoping detail that it happens in a specified folder. It is clear and actionable, but it does not distinguish this tool from siblings such as create_quiz_from_template, duplicate_quiz, or generate_ai_quiz.
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?
There is no explicit guidance on when to use this tool versus alternatives. The name implies creation, but the description provides no conditions, prerequisites, or exclusions. It leaves the agent to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт свой опрос из шаблона каталога — со всеми вопросами, логикой и оформлением. Дальше его правят обычными инструментами. Опрос создаётся черновиком: респонденты увидят его после publish_quiz. template_id берётся из search_quiz_templates.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Своё название опроса. По умолчанию берётся название шаблона. | |
| folder_id | Yes | ID папки, в которой создать опрос (folder://list). | |
| template_id | Yes | ID шаблона из search_quiz_templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (not read-only, not destructive, not idempotent). The description adds meaningful behavior beyond that: the quiz is created in draft state and becomes visible to respondents only after publish_quiz. It does not cover permissions or whether creation is reversible, hence not a 5.
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?
Four short, front-loaded sentences with no waste: purpose first, then editing path, draft/publish behavior, and parameter sourcing. Every sentence earns its place.
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 creation tool with no output schema, the description covers the essential lifecycle (template lookup, creation with inherited content, draft state, publish step). It lacks detail on what happens to the template after creation (independent copy vs. link) and any permission prerequisites, but is otherwise sufficient.
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?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only echoes that template_id comes from search_quiz_templates (already in the schema) and does not add format or defaulting nuance beyond that, so the baseline 3 applies.
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?
States a specific verb+resource ('Создаёт свой опрос из шаблона каталога') and immediately clarifies scope: the quiz is created with all questions, logic, and design carried over from the template. This implicitly distinguishes it from create_quiz (blank) and generate_ai_quiz, and it names search_quiz_templates as the template source, so an agent can tell what this produces.
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?
Gives clear workflow context: template_id comes from search_quiz_templates, further editing is done with regular tools, and visibility requires publish_quiz. It does not explicitly state when to prefer this over create_quiz or duplicate_quiz, but the usage path is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает скрытую переменную (extra field) для опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Опциональный UUID переменной (если не передан — генерируется автоматически). | |
| name | Yes | Название переменной. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/non-destructive/non-idempotent profile, so the bar is lower, but the description adds little beyond noting the variable is 'hidden'. It says nothing about permissions, scope (which quiz features consume the variable), or side effects.
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?
A single front-loaded sentence with no filler. It is efficient, though arguably under-specified rather than maximally concise.
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 mutation tool with no output schema, the description is too thin. It does not explain what a hidden variable affects or what the response returns, leaving the agent to infer behavior it cannot verify from structured fields.
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?
Schema description coverage is 100%, so both required params and the optional generated UUID are already documented in the schema. The description adds no syntax or semantic detail beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ('Создает скрытую переменную') and usefully equates it to an 'extra field' for the quiz, clarifying domain terminology. It does not, however, differentiate itself from near-siblings like create_hidden_option or create_answer_tag.
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?
The description offers no when-to-use guidance, no prerequisites, and does not point to alternatives such as update_quiz_variable or create_hidden_option. The agent gets no routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавляет вебхук к опросу. Создаётся выключенным: сначала проверьте отправкой, потом включите через toggle_quiz_webhook — так же устроено в интерфейсе. Адрес должен быть публичным http или https, внутренние адреса не принимаются.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Адрес, куда уходят данные. Только публичный http или https. | |
| body | No | Шаблон отправляемых данных: какие поля ответа слать. | |
| hours | No | Задержка перед отправкой в часах: 0, 1, 6, 12 или 24. Ноль — сразу. | |
| title | Yes | Название вебхука, до 255 символов. | |
| method | Yes | HTTP-метод: get, post, put или patch. | |
| headers | No | Дополнительные заголовки запроса, список из {"name": "...", "value": "..."}. | |
| quiz_id | Yes | ID опроса. | |
| incomplete | No | Слать и незавершённые ответы. | |
| body_naming | No | Переименование полей: свой ключ для каждого поля отправки. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety quartet (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds two genuinely non-obvious traits beyond that: the created object starts in a disabled state (a surprising default for a create call) and the URL must be public http/https with internal addresses rejected. That is real behavioral context the structured fields do not carry.
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?
Three short sentences, front-loaded with the action, then the disabled-by-default caveat, then the validation rule. No filler and no repetition — every clause carries distinct information.
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 9-parameter tool with nested objects and no output schema, the description covers purpose, the follow-up enable step, and the key input constraint. It leaves the return value (e.g. the new webhook id) and how body/body_naming templates behave unstated, though the latter is fully documented in the schema.
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?
Schema description coverage is 100%, and the description's URL constraint ('Адрес должен быть публичным http или https') merely restates the schema's own url description. With the schema doing the heavy lifting for all 9 params, the baseline 3 applies; no format or interaction details are added beyond the duplication.
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?
States a specific verb+resource ('Добавляет вебхук к опросу') and implicitly scopes it against the sibling webhook tools (update_quiz_webhook, toggle_quiz_webhook, delete_quiz_webhook, get_quiz_webhooks). An agent can tell this is the creation path without opening any schema.
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?
Gives an explicit workflow: the webhook is created disabled, you should first verify by sending, then enable it via toggle_quiz_webhook — the named alternative. This tells the agent both the immediate effect and the required follow-up call, which is exactly the routing information most definitions omit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет набор оформления в библиотеку аккаунта, чтобы применять его к другим опросам. Набор — это шаблон: его удаление или правка не меняют опросы, к которым его применяли.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название набора, до 40 символов. | |
| settings | Yes | Объект оформления — те же поля, что у update_workspace_report_palette. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive create operation, and the description adds valuable non-obvious behavior: the preset is a template whose deletion or editing does not affect surveys it was applied to. It does not cover permission needs or return behavior, but that is less critical with annotations present.
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?
Two sentences, both front-loaded with the key purpose and the template-independence rule. No filler or redundant restatement of the tool name.
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 create tool with a nested settings object and no output schema, the description covers purpose and a key behavioral caveat. It could mention workspace scoping more explicitly, but the schema already handles parameter details.
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?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds no parameter syntax or constraints beyond what the schema provides, so the baseline 3 is appropriate.
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 gives a specific verb ('Сохраняет' — saves) and a specific resource ('набор оформления' — appearance preset) plus its destination ('в библиотеку аккаунта'). It also defines the resource as a reusable template, which distinguishes it from direct palette updates.
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?
The description clearly implies the use case: create a reusable appearance preset to apply to other surveys. It does not state exclusions or name alternative tools such as update_workspace_report_palette, so it falls short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает тему внутри workspace и сразу применяет ее к опросу.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Название темы (опционально, max 255 символов). Если не передать — генерируется автоматически. | |
| quiz_id | Yes | ID опроса, к которому применяется тема. Должен принадлежать указанному workspace. | |
| bg_color | No | Цвет фона в формате #RRGGBB. Используется когда background_type_id=1. Например: #0f3460. | |
| base_font | No | Название базового шрифта строкой (например «Golos Text», «Montserrat»). Опционально, max 255 символов. Если пусто — используется дефолтный шрифт. | |
| custom_css | No | Свой CSS для страницы опроса, до 20000 символов. | |
| input_style | No | Стиль полей ввода: box — поле в рамке, underline — одна линия. | |
| base_font_id | No | ID базового шрифта. Популярные: 1=Native, 2=Roboto, 3=Open Sans, 4=Montserrat, 5=Source Sans Pro, 6=Merriweather, 9=PT Sans, 11=Ubuntu, 15=Rubik, 18=Comfortaa, 44=Golos Text. Полный список 1–44. | |
| header_color | No | Цвет заголовка в формате #RRGGBB. Например: #1a1a2e. | |
| heading_font | No | Отдельный шрифт заголовков, название гарнитуры Google Fonts. Пусто — шрифт как у остального текста. | |
| service_text | No | Служебный текст, до 500 символов. Простая разметка допустима, остальное вырезается. | |
| workspace_id | Yes | ID воркспейса. Взять из workspace://list. | |
| answer_border | No | Толщина рамки вариантов ответа в px (0–999). Например: 1. | |
| buttons_color | No | Цвет кнопок в формате #RRGGBB. Например: #3b82f6. | |
| buttons_radius | No | Скругление кнопок в px (0–999). Например: 8. | |
| progress_style | No | Индикатор прогресса: percent, line или steps. | |
| bg_gradient_end | No | Конечный цвет градиента в формате #RRGGBB. Например: #00ffd8. | |
| bg_logo_file_id | No | ID загруженного файла логотипа поверх фона (min:1). | |
| bg_logo_size_id | No | Размер логотипа на фоне: 0 — маленький, 1 — средний (по умолчанию), 2 — большой. | |
| buttons_type_id | No | Тип кнопок: 1=background (заливка цветом), 2=border (только рамка). | |
| container_width | No | Ширина содержимого: narrow, normal, wide или full. | |
| bg_image_file_id | No | ID загруженного файла фонового изображения (min:1). Используется когда background_type_id=1. | |
| bg_gradient_start | No | Начальный цвет градиента в формате #RRGGBB (ровно 6 hex-символов). Например: #00d4ff. | |
| button_full_width | No | Растянуть кнопку на всю ширину контейнера. | |
| dropdown_bg_color | No | Цвет фона раскрытого меню выпадающего списка в формате #RRGGBB (опционально). Если не передать — наследует bg_color. | |
| questions_size_id | No | Размер текста вопросов: 0 — маленький, 1 — средний, 2 — большой. | |
| service_text_size | No | Размер служебного текста: 12, 14 или 16. | |
| answers_text_color | No | Цвет текста ответов в формате #RRGGBB (опционально). Если не передать — наследует header_color. | |
| background_opacity | No | Прозрачность фона в процентах (0–100). 100 = непрозрачный. | |
| background_type_id | No | Тип фона: 1=color_image (цвет/изображение), 2=gradient (градиент). | |
| bg_gradient_vector | No | Направление градиента в градусах (0–360). Используется когда background_type_id=2. Пример: 90 = слева направо, 180 = сверху вниз. | |
| buttons_text_color | No | Цвет текста кнопок в формате #RRGGBB. Например: #ffffff. | |
| service_text_color | No | Цвет служебного текста в формате #RRGGBB. | |
| service_text_scope | No | Где показывать служебный текст: all — на всех экранах, welcome, questions или finish. | |
| background_contrast | No | Контраст фона (-100 – +100). 0 = без изменений. | |
| background_saturate | No | Насыщенность фона (-100 – +100). 0 = без изменений. | |
| bg_logo_position_id | No | Положение логотипа на фоне: 0 — слева (по умолчанию), 1 — по центру, 2 — справа. Нумерация своя, с background_position_id не совпадает. | |
| question_transition | No | Переход между вопросами: slide, fade, zoom, blur или none. | |
| widget_active_color | No | Цвет активного элемента виджета в формате #RRGGBB. Например: #e94560. | |
| background_lightness | No | Яркость фона (-100 – +100). 0 = без изменений. | |
| service_text_enabled | No | Показывать служебный текст — короткую строку для дисклеймера или согласия. | |
| answer_options_radius | No | Скругление вариантов ответа в px (0–999). Например: 4. | |
| questions_position_id | No | Выравнивание текста вопросов: 0 — слева, 1 — по центру. | |
| service_text_align_id | No | Выравнивание служебного текста: 0 — слева, 1 — по центру, 2 — справа. Справа работает только вместе с верхним размещением: внизу справа стоят стрелки навигации и бейдж WebAsk. | |
| background_position_id | No | Позиция фона: 1=center center, 2=left center, 3=right center, 4=center top, 5=left top, 6=right top, 7=center bottom, 8=left bottom, 9=right bottom. | |
| background_placement_id | No | Размещение фона: 1=stretch (растянуть), 2=drawin (вписать), 3=cover (заполнить). | |
| service_text_placement_id | No | Где на экране стоит служебный текст: 0 — снизу, 1 — сверху. | |
| welcome_and_finish_size_id | No | Размер текста на приветствии и завершении: 0 — маленький, 1 — средний, 2 — большой. | |
| welcome_and_finish_position_id | No | Выравнивание текста на приветствии и завершении: 0 — слева, 1 — по центру. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, non-idempotent, non-destructive, closed-world. The description adds one genuine behavioral fact beyond them: the created theme is immediately applied to the quiz, a side effect not expressed by the hints. It omits auth/permission needs and confirmation behavior.
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?
A single short sentence, front-loaded with the verb and resource, with zero filler. Nothing is wasted.
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 48-parameter tool with no output schema, this is thin: it explains the core action and side effect but says nothing about what the call returns (e.g. new theme id), so the agent cannot plan follow-up calls from the description alone.
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?
Schema description coverage is 100% across all 48 parameters, so the schema fully carries parameter meaning. The description adds no parameter-level detail, which is acceptable at this coverage level but adds no extra value.
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?
States a specific verb+resource ('Создает тему') plus scope ('внутри workspace') and a distinguishing side effect ('сразу применяет ее к опросу'). An agent can tell it apart from a pure apply/update, though no sibling (apply_quiz_theme, update_theme, manage_theme) is named.
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?
The auto-apply detail hints at when this is useful, but there is no explicit when-to-use, when-not, or alternative (e.g. update_theme for existing themes, apply_quiz_theme for reuse). The agent must infer routing from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет тег ответов из аккаунта вместе со всеми его привязками к ответам. Чтобы снять тег с одного ответа, используйте tag_answer.
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | ID тега (из get_answer_tags). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the deletion cascades to all answer-tag bindings, which is a consequence an agent could not infer from the annotations. It stops short of stating irreversibility or required permissions, so not a 5.
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?
Two short sentences, zero filler, with the cascade scope stated first and the routing hint second. Nothing in it is redundant with structured fields.
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 destructive two-parameter tool with full schema coverage, no output schema, and destructive/ non-idempotent annotations, the description supplies the missing piece (the cascade to bindings) and the alternative tool. It could go slightly further on irreversibility or permissions, but nothing essential is missing.
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?
Schema description coverage is 100% and both parameters (tag_id, workspace_id) already document their source (get_answer_tags, workspace://list). The description adds no additional parameter meaning, so the baseline 3 applies.
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 states a specific verb and resource ("Удаляет тег ответов") and clarifies scope: the tag is removed from the account together with all of its bindings to answers. It also names the sibling that does the narrower operation (tag_answer), so an agent can distinguish the two without opening either schema.
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?
It explicitly routes the agent: use this tool when you want to delete the whole tag, and use tag_answer when you only want to detach the tag from a single answer. That is a concrete when-to-use / when-to-use-something-else statement rather than implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Снимает блокировку и снова открывает время для записи.
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID блокировки (из get_booking_journal, ключ blocks). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is an irreversible-feeling write. The description adds the outcome that the time becomes bookable again, but says nothing about whether the block is permanently lost or what the response provides. Useful but thin against a destructive operation.
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?
A single short, front-loaded sentence with zero filler. Nothing redundant or padded.
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 two-parameter destructive tool with full schema coverage and annotations carrying the safety profile, the description is minimally adequate. It states the effect but omits when-to-use guidance and any note on the block disappearing, which an agent would want before calling it.
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?
Schema description coverage is 100% and both parameters document their source (block_id from get_booking_journal blocks key, workspace_id from workspace://list). The description contributes no additional parameter meaning, so the baseline of 3 applies.
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 names a specific action and resource: removing a booking block and reopening the time slot. It is clearly distinguishable from create_booking_block in the sibling list, though it never names that counterpart explicitly.
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?
There is no indication of when to use this versus update_booking or create_booking_block, and no prerequisites (e.g., that the block must still exist) or exclusions are stated. Usage is only weakly implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Убирает вопрос из библиотеки аккаунта. В опросах, куда его добавляли, вопрос остаётся.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). | |
| favorite_question_id | Yes | ID вопроса (из get_favorite_questions). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the deletion is scoped to the library and does not cascade into quizzes where the question was added. It stops short of saying whether the removal is reversible or which permissions are needed.
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?
Two short sentences with zero padding; the action is front-loaded and the clarifying scope constraint follows immediately.
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 2-parameter delete tool with full schema coverage, no output schema and annotations carrying the safety profile, the description supplies the one fact that could otherwise mislead (no cascade into quizzes). Missing only minor details such as reversibility.
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?
Schema description coverage is 100% and both parameters are documented in-schema, including where to obtain the IDs (workspace://list, get_favorite_questions). The description adds no parameter-level meaning, so the baseline 3 applies.
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?
States a specific verb+resource: it removes a question from the account's favorite-question library. The second sentence clarifies the scope boundary (quizzes keep the question), which separates it from delete-type siblings, though no sibling is named explicitly.
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?
Usage is implied by the scope statement — an agent can infer this is not the tool for removing questions from surveys — but there is no explicit when-to-use, when-not, or named alternative (e.g. delete_quiz_answers) and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет опрос (мягкое удаление, с возможностью восстановления).
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса для удаления. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description adds critical context that deletion is soft and reversible, which is not in the annotations. It still lacks details on side effects, permissions, or cascading behavior.
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?
A single sentence that is front-loaded with the action and immediately qualifies it as a soft delete with restoration. Every word earns its place.
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 simple one-parameter delete tool with annotations and no output schema, the description covers the essential reversible nature of the operation. It could mention the restoration path or prerequisites, but it is largely complete.
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?
Schema description coverage is 100%, so the schema already fully documents the single quiz_id parameter. The description adds no additional meaning beyond what the schema provides, matching the baseline of 3.
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?
States a specific verb ('Удаляет') and resource ('опрос'), and clarifies that deletion is soft with restoration. It does not differentiate from sibling archive_quiz or delete_quiz_answers, so it falls short of a 5.
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 when-to-use or alternatives are given. The description does not mention archive_quiz as a non-destructive alternative or restore_quiz for recovery. Usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Убирает ответы в корзину, возвращает их оттуда или удаляет безвозвратно. Обычное удаление обратимо: ответ пропадает из списка и отчёта, но лежит в корзине. Безвозвратное необратимо — вместе с ответом убираются и файлы, которые загрузил респондент, поэтому нужен отдельный признак confirm_purge. Скрытые и отправленные на модерацию ответы не затрагиваются.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Над чем работать: selected — над перечисленными в answer_ids (по умолчанию), all — над всеми ответами опроса. При all список id не нужен, а действие требует confirm_purge. | |
| action | Yes | trash — в корзину, restore — вернуть из корзины, purge — удалить безвозвратно. | |
| quiz_id | Yes | ID опроса. | |
| answer_ids | No | ID ответов, до 500 за раз. Берите их из quiz://{id}/answers. Обязателен при scope=selected, то есть в обычном случае; при scope=all не передаётся. | |
| confirm_purge | No | Обязателен и должен быть true для действия purge: подтверждение, что ответы и файлы удаляются насовсем. | |
| excluded_answer_ids | No | При scope=all — ответы, которые нужно оставить как есть, до 500 штук. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and non-idempotence, but the description goes well beyond them: it explains that trash is reversible while purge is not, that purge additionally destroys respondent-uploaded files, that a separate confirm_purge flag gates it, and that hidden/moderated answers are excluded. This is exactly the destructive-scope context an agent needs.
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?
Four front-loaded sentences cover action modes, reversibility, and exclusions with no filler. Minor redundancy ("irreversible is irreversible") keeps it just short of a 5, but sizing is appropriate for a multi-mode destructive tool.
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 six-parameter mutation tool with no output schema, the description covers what is destroyed, reversibility, the confirmation gate, side effects on files, and excluded categories. An agent has everything needed to invoke it safely; only auth/permission context is absent, which is a minor gap.
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?
Schema coverage is 100% and each parameter is already documented in the schema. The description reinforces confirm_purge's purpose and rationale (file deletion) but adds almost no syntax or format detail beyond what the schema states, so the baseline of 3 applies.
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 names the resource (ответы/quiz answers) and the exact verb set it performs: trash, restore, or permanent delete. It explicitly distinguishes the three modes and states the exclusion (hidden and moderation-pending answers are untouched), so an agent can tell it apart from siblings like delete_answer_tag or toggle_answer_visibility.
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?
It clearly maps each action to its situation: normal deletion is reversible and lands in the trash, irreversible deletion requires confirm_purge and also removes respondent files. It does not name alternative sibling tools for adjacent tasks, but the when-to-use-each-action guidance is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Убирает адрес из уведомлений автору.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| email_id | Yes | ID адреса (из get_quiz_email_settings). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: it doesn't say whether removal is permanent, whether the address can be re-added, or that the quiz_id scopes the operation to one quiz.
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?
A single short sentence with the action front-loaded and no filler. It is efficient, though the terseness leaves the definition under-informative for a destructive operation.
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 two-parameter destructive mutation with no output schema, the annotations cover the safety hint and the schema covers the inputs, so the minimum bar is met. What is missing is confirmation that the deletion is irreversible and how it relates to toggle_quiz_email_recipient.
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?
Schema coverage is 100%, so both quiz_id and email_id are already documented in the schema, including the pointer to get_quiz_email_settings. The description only alludes to 'адрес' and adds no meaning beyond the schema; baseline 3 applies.
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?
States a specific verb and resource: it removes an email address from the author's notification list. It is distinguishable from add_quiz_email_recipient and toggle_quiz_email_recipient by the delete verb, though it never names those siblings explicitly.
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 when-to-use guidance and no mention of the closely related toggle_quiz_email_recipient, which an agent could reasonably prefer if the goal is temporary suppression rather than removal. The agent must infer the choice from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет скрытую переменную (extra field) из опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| field_id | Yes | UUID скрытой переменной. Взять из quiz://{id}/variables. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that: it never says what collateral effect deleting a variable has (e.g., whether collected answer values for that field are lost) or whether the deletion is recoverable, which is the key context an agent needs for a destructive operation.
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?
A single tight sentence with no filler and the action front-loaded. It is efficient, though its brevity edges toward under-specification rather than optimal informativeness.
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 destructive delete with two required identifiers and no output schema, the description omits the consequences of deletion and any recovery note. Annotations cover the safety flag, but the agent still lacks enough context to predict the operation's blast radius.
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?
Schema description coverage is 100%, and field_id already tells the agent to source the UUID from quiz://{id}/variables, so the schema is doing the documentation work. The description adds no additional parameter meaning. Baseline 3 applies.
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?
States a specific verb and resource: 'Удаляет скрытую переменную (extra field) из опроса.' The parenthetical maps the internal term to the domain concept (extra field), which helps. It stops short of distinguishing itself from close siblings like delete_hidden_option or update_quiz_variable.
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 when-to-use guidance and no mention of alternatives. It doesn't tell the agent how this differs from delete_hidden_option, update_quiz_variable, or removing the variable another way, leaving selection entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет вебхук опроса вместе с его заголовками и журналом отправок.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| webhook_id | Yes | ID вебхука (из get_quiz_webhooks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the deletion cascades to webhook headers and the send log. It stops short of 5 because it says nothing about irreversibility, permissions, or effect on related log entries.
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?
A single front-loaded sentence with no filler; the verb and the cascade consequence are packed efficiently. There is little room to improve, though it is minimal rather than exemplary in 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 two-parameter destructive tool with full schema coverage, complete annotations, and no output schema, the description covers the important unknown: what else is destroyed. Missing only permanence/permission notes, which keeps it from a 5.
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?
Schema description coverage is 100%, with both quiz_id and webhook_id documented in the schema (including a pointer to get_quiz_webhooks). The description adds no parameter-level detail, so the baseline of 3 applies.
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 states a specific verb and resource ('Удаляет вебхук опроса') and additionally notes that headers and the send log are removed, which sharpens the scope. It does not explicitly distinguish itself from siblings like toggle_quiz_webhook or update_quiz_webhook, so it falls short of a 5.
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?
There is no guidance on when to delete versus simply disabling via toggle_quiz_webhook, nor any prerequisite or warning about permanence. The intended usage is only implied by the verb 'удаляет'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет набор оформления из библиотеки аккаунта. Опросы, к которым его применяли, своё оформление сохраняют.
| Name | Required | Description | Default |
|---|---|---|---|
| preset_id | Yes | ID набора (из get_workspace_report_appearance). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds valuable context beyond annotations by clarifying that surveys using the preset keep their own appearance, which is a key behavioral consequence for an agent to understand.
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?
Two short sentences with zero waste, front-loading the core deletion action and then the important side effect. Every sentence earns its place.
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 simple two-parameter deletion tool with full schema coverage and annotations covering the destructive nature, the description is nearly complete. It omits any mention of irreversibility or restoration, but the destructiveHint annotation partly compensates and the main behavioral caveat is covered.
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?
Schema description coverage is 100%, with both parameters documented in the schema itself (preset_id sourced from get_workspace_report_appearance, workspace_id from workspace://list). The description adds no additional parameter meaning, so the baseline 3 applies.
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 states a specific verb ('Удаляет') and resource ('набор оформления') with the location ('из библиотеки аккаунта'), making the purpose unambiguous. It does not explicitly contrast with sibling tools like create_report_appearance_preset, but the delete operation is inherently distinct.
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?
There is no guidance on when to use this tool versus alternatives or what prerequisites exist. The description mentions the effect on quizzes, but that is behavioral context rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет расписание записи вместе с его записями и блокировками времени — вернуть их нельзя. Если нужно просто перестать принимать записи, выключите расписание через save_scheduler (is_active).
| Name | Required | Description | Default |
|---|---|---|---|
| scheduler_id | Yes | ID расписания (из get_schedulers). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and non-idempotency, but the description adds the critical context annotations cannot convey: which dependent data (bookings, time blocks) is destroyed and that it is unrecoverable. That is exactly the 'what gets destroyed' disclosure that raises the bar beyond structured hints.
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?
Two sentences, both load-bearing: the first delivers the destruction scope and irreversibility, the second delivers the safer alternative. No filler and the irreversible consequence is front-loaded.
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?
No output schema exists and none is needed for a delete. With annotations covering the safety profile and the description covering data loss and the alternative path, an agent has everything required to decide whether to call it.
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?
Schema description coverage is 100% and both parameters are documented with sourcing hints (scheduler_id from get_schedulers, workspace_id from workspace://list). The description adds nothing about parameters, so the baseline 3 applies.
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?
States a specific verb and resource (delete the booking schedule) and immediately scopes the blast radius by naming the dependent entities removed with it (bookings and time blocks). An agent can distinguish it from sibling tools like get_schedulers or duplicate_scheduler without opening the schema.
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?
Explicitly names the when-not case and the alternative: if the goal is merely to stop accepting bookings, use save_scheduler (is_active) instead. This routes the agent away from an irreversible action when a reversible one suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет логотип рабочего пространства.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID рабочего пространства. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no statement about irreversibility, required permissions/role, or side effects such as reverting to a default branding image.
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 sentence with zero waste, but it is under-specified rather than genuinely concise — the brevity comes at the cost of any behavioural or usage context. Front-loading is fine since there is only one clause.
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?
Annotations and the schema already cover the destructive/idempotency profile and the single parameter, and no output schema exists so return values are unneeded. Still, for a destructive operation the description omits any note on permission requirements or what state the workspace ends up in after the logo is removed.
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?
There is a single parameter and schema description coverage is 100%, with the schema explaining that workspace_id comes from workspace://list. The description adds no parameter meaning, so the baseline of 3 applies.
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 states a specific verb and resource ('Удаляет логотип рабочего пространства'), so an agent immediately knows what the tool does. It does not differentiate itself from near-siblings such as upload_workspace_logo or update_workspace_branding, and it is essentially a translation of the tool name, but the purpose itself is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g. that a logo must already exist), and no note that upload_workspace_logo replaces or overwrites the logo. An agent gets no routing help at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Удаляет роль аккаунта. Участники этой роли переводятся на роль по умолчанию, то есть их возможности меняются. Встроенные роли удалить нельзя.
| Name | Required | Description | Default |
|---|---|---|---|
| role_id | Yes | ID роли (из get_workspace_roles). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, yet the description adds non-obvious behavior: members of the deleted role are migrated to the default role and their capabilities change, plus built-in roles are protected. This side-effect disclosure is exactly what an agent needs before a destructive call, though permission requirements and irreversibility are not addressed.
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?
Three short sentences with the core action front-loaded, then the side-effect, then the constraint. No filler; every sentence carries information.
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 two-parameter destructive mutation with annotations covering the safety profile and no output schema, the description supplies the two things structured fields cannot: the member-migration side-effect and the built-in-role restriction. Adequate, with only minor gaps around permissions/undo.
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?
Schema description coverage is 100%, and both role_id and workspace_id already document their origin (get_workspace_roles, workspace://list). The description adds no parameter-level detail, so the baseline of 3 applies.
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?
States a specific verb and resource ('Удаляет роль аккаунта'), so the action is unambiguous and clearly distinct from save_workspace_role and get_workspace_roles. It does not explicitly name those siblings as alternatives, keeping it at a solid 4 rather than 5.
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?
The description gives a real precondition ('Встроенные роли удалить нельзя'), which tells the agent when the call will fail, but it never states when to delete a role versus reassigning it (set_workspace_member_role) or saving an edit (save_workspace_role). Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает копию существующего опроса со всеми данными и версиями.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Опциональное название нового опроса (максимум 80 символов). | |
| quiz_id | Yes | ID опроса, который нужно дублировать. | |
| folder_id | No | ID папки, в которую положить копию. По умолчанию копия ложится рядом с оригиналом. Копирование в другую папку требует отдельного права. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description contributes one useful behavioral fact — the copy includes all data and versions — but says nothing about default naming, what is excluded, or whether repeated calls create further copies.
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 front-loaded sentence that states the action and scope with no filler. Nothing redundant or padded.
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 simple duplication tool with full schema coverage and annotations, this is close to sufficient. However, with no output schema the description could have said what the result is (the new quiz and its ID), and it omits any mention of naming behavior or folder permissions outside the schema.
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?
Schema description coverage is 100%, and the schema already explains name, quiz_id, and the folder_id default/permission nuance. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource: creates a copy of an existing quiz, with scope 'со всеми данными и версиями'. This clearly separates it from create_quiz or create_quiz_from_template, though it never names those siblings explicitly.
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 when-to-use guidance at all. The agent gets no signal on when to duplicate versus create a quiz, use a template, or make_quiz_template, and no prerequisites (e.g. permission needed for cross-folder copies) are mentioned in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Копирует расписание записи. Настройки копируются, записи — нет: удобно завести похожее расписание с другой длительностью или другими часами.
| Name | Required | Description | Default |
|---|---|---|---|
| scheduler_id | Yes | ID расписания (из get_schedulers). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare this is a non-read, non-destructive, non-idempotent write. The description adds genuinely useful behavioral detail beyond that: settings are duplicated but existing bookings are not ('Настройки копируются, записи — нет'), which is exactly the kind of scoping an agent needs for a duplicate operation. It omits permissions or where the copy is named/stored.
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?
Two tight sentences: the first states the operation, the second states the crucial settings-vs-records distinction and the motivating use case. Nothing is wasted and the key constraint is front-loaded.
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 2-parameter duplicate tool with no output schema, the definition covers purpose, what gets copied vs not, and a use case. The main remaining gap is that, absent an output schema, it never indicates what the call returns (e.g. the new scheduler's ID), which an agent might need.
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?
Schema description coverage is 100%, and both parameters carry their own descriptions with provenance hints (scheduler_id from get_schedulers, workspace_id from workspace://list). The description adds no parameter-level detail, so the baseline of 3 applies.
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?
States a specific verb and resource ('Копирует расписание записи' – copies a booking schedule), so the operation is unambiguous. It does not explicitly contrast itself with sibling tools like save_scheduler or duplicate_quiz, but the copy semantics are self-evident.
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?
Provides an explicit use case: creating a similar schedule with a different duration or different hours ('удобно завести похожее расписание с другой длительностью или другими часами'). It stops short of naming alternatives or stating when NOT to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует ответы опроса в CSV и возвращает ссылку на скачивание файла (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Опциональные ID ответов для включения. | |
| quiz_id | Yes | ID опроса. | |
| is_deleted | No | Брать удалённые ответы вместо активных (по умолчанию false). | |
| excludedIds | No | Опциональные ID ответов для исключения. | |
| is_complete | No | Только завершённые ответы (по умолчанию true). | |
| is_screenout | No | Включать ответы, дисквалифицированные логикой (по умолчанию false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds one genuinely useful behavioral fact outside the annotations: the download link expires after 1 hour. That is a real operational constraint an agent must handle, but nothing is said about rate limits, size caps, async generation, or how long large exports take.
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 sentence, front-loaded with the action and format, then the return value and its expiry. No filler, nothing repeated from the schema.
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 read-only export with a fully documented schema and clear annotations, the description supplies the two things it must: output form (download link) and lifetime (1 hour). The remaining gap is routing among the CSV/XLSX/SPSS/Word export siblings, which is the tool's most likely misuse path given the sibling list.
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?
Schema description coverage is 100%, with each of the 6 parameters documented in Russian (including defaults for is_deleted, is_complete, is_screenout). The description adds no parameter details, so it cannot exceed the baseline. The 1-hour-link fact is return-value info, not parameter info.
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?
States a specific verb (экспортирует) and resource (ответы опроса в CSV), and the return value is named explicitly (ссылка на скачивание). The sibling set includes export_answers_spss/word/xlsx and export_quiz_print, so the format ('CSV') is the key differentiator and it is stated directly in the name and description.
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?
There is no when-to-use guidance or routing to alternatives. The five sibling export_* tools mean an agent needs to know which format to pick and under what conditions; nothing in the text tells it when CSV is preferable to XLSX/SPSS/Word, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Выгружает ответы опроса в формат SPSS (.sav) — тот же набор данных, что в CSV и XLSX, но в виде, который открывают статистические пакеты. Вместе с ответами в файл идут параметры ссылки, иначе часть колонок осталась бы безымянной. Возвращает ссылку на скачивание, действительную час. Выгрузка результатов доступна не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Выгрузить только эти ответы по их ID. | |
| quiz_id | Yes | ID опроса. | |
| is_deleted | No | Взять ответы из корзины вместо обычных. | |
| excludedIds | No | Исключить эти ответы по их ID. | |
| is_complete | No | Только завершённые прохождения. По умолчанию да. | |
| is_screenout | No | Включить отсеянных респондентов. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive). The description adds real behavioral context: the return is a download link valid for one hour, the exported file includes link parameters to keep columns named, and the feature is tariff-gated. This is meaningful beyond the annotations, though it omits things like expiry/regeneration behavior.
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?
Four front-loaded sentences: purpose, dataset equivalence, payload composition, return value and access constraint. Efficient and well ordered, with only minor redundancy in restating the CSV/XLSX equivalence.
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 6-param export tool with no output schema, the description covers format, data equivalence, file contents, return value with validity window, and the tariff gate. It is largely complete; a note on link regeneration or file size limits would make it fully self-contained.
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?
Schema description coverage is 100% (all six params documented in the schema), so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides, but it needn't.
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?
States a specific verb (Выгружает) plus resource (ответы опроса) and format (.sav), and explicitly distinguishes itself from the CSV/XLSX siblings by noting it is 'тот же набор данных, что в CSV и XLSX, но в виде, который открывают статистические пакеты'. An agent can tell it apart from export_answers_csv/xlsx/word without opening the schema.
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?
Identifies the usage context (statistical packages) and contrasts with sibling export formats, and discloses a gating condition ('Выгрузка результатов доступна не на всех тарифах'). It does not however give an explicit 'use this when X, otherwise use export_answers_csv' routing rule, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует ответы опроса в Word и возвращает ссылку на скачивание (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Опциональные ID ответов для включения. | |
| quiz_id | Yes | ID опроса. | |
| is_deleted | No | Брать удалённые ответы вместо активных (по умолчанию false). | |
| excludedIds | No | Опциональные ID ответов для исключения. | |
| is_complete | No | Только завершённые ответы (по умолчанию true). | |
| is_screenout | No | Включать ответы, дисквалифицированные логикой (по умолчанию false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, non-destructive read. The description adds genuinely new behavioral context: the tool produces a download link rather than inline data, and that link expires after one hour — an operational constraint not derivable from the schema or annotations. It still doesn't say whether the export is generated synchronously or how a large selection affects latency.
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?
A single sentence with the action first and the most decision-relevant detail (the one-hour link lifetime) attached. Nothing is padded and nothing unnecessary precedes the verb.
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?
There is no output schema, and the description does cover the return artifact and its TTL, which is the most important missing piece. However, with six filter parameters and no guidance on when this exporter is preferred over its PDF/CSV/XLSX siblings, the definition is adequate but leaves real gaps.
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?
Schema description coverage is 100% — every one of the six parameters, including the ids/excludedIds interaction and the is_deleted/is_complete/is_screenout defaults, is documented in the schema itself. The description adds no filtering semantics, so the baseline 3 applies.
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?
States a specific verb and resource ('Экспортирует ответы опроса в Word') and names the output format, which implicitly separates it from the CSV/SPSS/XLSX export siblings. It does not explicitly name those alternatives, so differentiation is left to the agent to infer.
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 when-to-use guidance, no prerequisites, and no mention of the sibling exporters (export_answers_csv, export_answers_xlsx, export_answers_spss) that an agent must choose between. The agent must guess which format tool fits the request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует ответы опроса в Excel (XLSX) и возвращает ссылку на скачивание файла (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Опциональные ID ответов для включения. | |
| quiz_id | Yes | ID опроса. | |
| is_deleted | No | Брать удалённые ответы вместо активных (по умолчанию false). | |
| excludedIds | No | Опциональные ID ответов для исключения. | |
| is_complete | No | Только завершённые ответы (по умолчанию true). | |
| is_screenout | No | Включать ответы, дисквалифицированные логикой (по умолчанию false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it returns a download link and specifies that the link is valid for 1 hour, which is operationally important for an export tool.
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?
A single, front-loaded sentence that states the action, output format, and return behavior. Every clause earns its place with no redundancy or filler.
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?
The tool has no output schema, so the description usefully specifies that it returns a download link with a 1-hour lifetime. Combined with the rich schema descriptions and annotation coverage, this is nearly complete; minor gaps like default filtering behavior are covered by the schema.
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?
Schema description coverage is 100%, so the schema already documents all six parameters (including optional filters like ids, excludedIds, is_deleted, is_complete, and is_screenout). The description adds no parameter-level details beyond what the schema provides, so the baseline of 3 is appropriate.
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?
States a specific verb (экспортирует), resource (ответы опроса), and format (Excel XLSX). This implicitly distinguishes it from sibling exports like export_answers_csv, export_answers_spss, and export_answers_word, though it does not name those alternatives explicitly.
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?
Provides no guidance on when to choose this tool over export_answers_csv, export_answers_spss, or export_answers_word. It only describes what the tool does, leaving the agent to infer the selection context from the format alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует фильтрованный отчёт опроса в PDF и возвращает ссылку на скачивание (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent read operation. The description adds valuable behavioral context beyond the annotations: the tool returns a download link and that link expires after 1 hour.
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?
A single sentence, front-loaded with the action and output, and the return-link expiry is appended without clutter. Every phrase earns its place.
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 simple one-parameter export with no output schema and clear annotations, the description is nearly complete: it covers purpose, output artifact, and link lifetime. A minor gap is that it does not clarify how the report filtering is determined (e.g., whether it relies on saved report filters or defaults), which could matter to an agent deciding whether quiz_id alone is sufficient.
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?
Schema coverage is 100%, and the only parameter quiz_id is described as 'ID опроса.' The description mentions 'отчёт опроса' but adds no syntax, format, or constraints beyond what the schema already provides.
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 states a specific verb (экспортирует), resource (фильтрованный отчёт опроса), and output format (PDF). It distinguishes itself from sibling exports such as export_filtered_report_word and export_summary_pdf by naming both the filtered scope and the PDF format.
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?
The description implies when to use it (to obtain a filtered report as a PDF) but does not explicitly say when to choose it over alternatives like export_filtered_report_word or generate_filtered_report. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует фильтрованный отчёт опроса в Word и возвращает ссылку на скачивание (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is low. The description usefully goes beyond them by disclosing the return value (a download link) and its one-hour expiry, which is genuinely actionable context an agent would not otherwise have.
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?
A single front-loaded sentence that carries the action, the format, and the link-expiry detail with zero filler. Appropriately sized for a one-parameter tool.
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 simple export tool with one fully documented parameter, annotations covering the safety profile, and no output schema, the description is nearly complete. It could still state that the underlying filtered report/filters must already exist, but nothing critical to correct invocation is missing.
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?
There is one parameter with 100% schema description coverage, so the schema already documents quiz_id fully. The description adds no semantics about the parameter, making the baseline 3 correct.
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?
States a specific verb (export), resource (filtered survey report), and output format (Word), which inherently distinguishes it from export_filtered_report_pdf (PDF) and export_answers_word (answers vs report). However, it never names the sibling it competes with, so an agent must infer the routing from the format word alone.
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?
The description gives no when-to-use guidance or alternatives. With a near-identical sibling in export_filtered_report_pdf, telling the agent to pick this one specifically for Word output would have been the obvious, cheap win; that guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Собирает печатную версию опроса — раздать на встрече, отдать на согласование, заполнить от руки. Форматы: pdf, word, txt, html. Возвращает ссылку на скачивание, действительную час. Речь о самих вопросах, а не об ответах: ответы выгружают export_answers_* .
| Name | Required | Description | Default |
|---|---|---|---|
| font | No | Размер шрифта печатной страницы: little, medium (по умолчанию), large. | |
| sheet | No | Что будет на листе — как в разделе «Печать» кабинета. Не передан — лист печатается как раньше. Неуказанное поле берёт значение по умолчанию. | |
| format | No | Формат файла: pdf (по умолчанию), word, txt, html. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive safety, but the description adds genuinely new behavior: the return is a download link valid for one hour (TTL limits retries) and the scope is questions not answers. It doesn't describe failure cases or rate limits, so not a 5, but well beyond 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?
Four short sentences, purpose front-loaded, then formats, then return behavior, then scope boundary. No filler or repetition; each sentence carries distinct information.
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?
No output schema, but the description compensates by stating the return value (time-limited download link). Combined with the fully documented nested sheet object, an agent has everything needed to call the tool correctly.
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?
Schema description coverage is 100%, including per-field defaults and format caveats (txt ignores qr/logo, paper only for pdf/word). The description only restates the format enum already in the schema and adds no new parameter syntax, so the baseline 3 applies.
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?
States a specific verb ("Собирает печатную версию опроса" / assembles a printed version) and resource, plus concrete scenarios (hand out, approval, fill by hand). It explicitly distinguishes itself from export_answers_* siblings, which share the export_ prefix.
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?
Names three concrete use cases and, crucially, states the exclusion + alternative: this is about the questions, not the answers, and answers go through export_answers_*. An agent can route correctly without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Экспортирует сводку (summary) опроса в PDF и возвращает ссылку на скачивание (действует 1 час).
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior not in the annotations: the returned link expires after one hour. It still does not say whether a file is persisted in workspace storage, whether repeated calls re-issue the link, or whether tariff limits apply.
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 front-loaded sentence that covers action, resource, output format, return value, and link lifetime with zero filler.
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?
With no output schema present, the description correctly fills the gap by describing the return value and its one-hour validity. It is largely complete for a one-parameter export tool, though it omits any note on link regeneration or storage side effects.
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?
There is a single parameter (quiz_id) with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the parameter (e.g. where to obtain the ID), making the baseline 3 appropriate.
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?
States a specific verb (экспортирует), resource (сводку опроса) and output format (PDF), plus the return artifact (ссылка на скачивание). It implicitly separates itself from export_answers_* and export_filtered_report_pdf by naming the summary scope, but it never explicitly distinguishes itself from those siblings.
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?
Usage is only implied: the agent can infer this is the tool for a PDF summary export. There is no explicit when-to-use guidance, no mention of alternatives such as get_quiz_summary or share_summary_link, and no stated prerequisites or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Собирает опрос по текстовому описанию. Сборка идёт в фоне: вызов возвращает ID будущего опроса и ставит работу в очередь, а сам опрос сначала пустой. Готовность спрашивают этим же инструментом, передав quiz_id — придёт pending или ready. Так же это устроено в кабинете; синхронной сборки нет, потому что обращения к модели занимают до минуты и обрывались по таймауту.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Пользовательское описание того, какой опрос нужно создать. | |
| ai_type | No | Что собирать: quiz — обычный опрос, у вопросов нет правильных ответов; test — тест, где у вариантов проставлены баллы и отмечены правильные ответы, а респондент в конце получает результат. По умолчанию quiz. | |
| project | No | Метка проекта для своего учёта: произвольная строка, которая просто сохраняется у опроса. На поведение не влияет, респондент её не видит. Не просите её у человека сами. | |
| quiz_id | No | ID опроса из предыдущего вызова. Передайте его, чтобы узнать, готова ли сборка. Вместе с ним folder_id и prompt не нужны. | |
| folder_id | No | ID папки, в которой нужно создать AI-опрос. Взять из folder://list. | |
| with_logic | No | Просить ли AI сразу построить логику переходов между вопросами (ветвление по ответам). Без неё вопросы идут подряд. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the annotations: the call returns immediately with an ID and enqueues work, the quiz starts empty, readiness is polled via the same tool returning pending/ready, and synchronous assembly was deliberately removed due to ~1 minute model calls timeouts. This is exactly the async contract an agent needs and the annotations (readOnly=false, destructive=false) do not convey.
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?
Four sentences, front-loaded with what it does, then the async behavior and readiness polling. The closing rationale about timeouts earns its place by explaining behavior. Slightly dense but no wasted filler.
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 an async, dual-mode tool with no output schema, the description fully covers the return contract (ID on start, pending/ready on poll) and the sequencing the agent must follow. Nothing needed to invoke it correctly is missing.
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?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: quiz_id is not just an ID but the polling key, and it explains the mutually exclusive create-vs-poll usage of prompt/folder_id versus quiz_id. That contextualizes the parameters beyond their individual schema descriptions.
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?
States a specific verb+resource: it assembles a quiz from a text description, and clarifies this is background/async generation rather than a manual build. This distinguishes it well from a plain create_quiz conceptually, though it never names create_quiz or create_quiz_from_template as explicit alternatives.
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?
Clearly establishes the two modes of use: call to start generation, then call again with quiz_id to poll readiness. It also explains why there is no synchronous path (model latency/timeouts). It stops short of telling the agent when to prefer this over create_quiz or create_quiz_from_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Строит AI-отчёт по ответам опроса. Отчёт состоит из трёх независимых разделов — текстовый анализ, сравнительный и количественный, — и каждый можно строить отдельно: перебирать формулировки в текстовом, не пересобирая остальное. Работа идёт в очереди: инструмент сообщает, что раздел поставлен в работу, а готовый текст забирает get_ai_report. Повторный запуск того же раздела, пока он строится, ничего не ломает. Тариф ограничивает число опросов с отчётом; пересборка уже существующего отчёта лимит не расходует.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Язык отчёта. По умолчанию берётся язык владельца ключа. | |
| quiz_id | Yes | ID опроса. | |
| section | No | Какой раздел построить: all — все три (по умолчанию), text_analysis — текстовый анализ, comparative — сравнительный, quantitative — количественный. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-idempotent, non-destructive. The description adds rich behavioral context: asynchronous queueing, that the tool only acknowledges queuing, retrieval via get_ai_report, that re-running a section mid-build is safe, and that rebuilding an existing report doesn't count against the tariff limit. This goes well beyond 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?
Front-loaded with the core purpose, then details sections, queueing, fetching, and quota. Four sentences, each contributing useful information. Slightly dense but no waste; could be trimmed marginally.
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?
Given no output schema, the description covers the essential async behavior, result retrieval tool, safety of repeated calls, and quota implications. An agent has all necessary context to invoke correctly and set expectations.
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?
Schema description coverage is 100%, so the schema already documents quiz_id, locale, and the section enum. The description adds some workflow nuance about sections being independent, but does not provide additional parameter syntax or formats. Baseline 3 is appropriate.
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?
States a specific verb and resource: builds an AI report from survey answers. It further decomposes the report into three independent sections, distinguishing it from the retrieval sibling get_ai_report. An agent can tell exactly what this tool does.
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?
Clearly outlines the workflow: use this to queue report generation, then fetch results with get_ai_report. Also notes that sections can be built independently and that repeated launches are safe, plus tariff constraints. No explicit 'when not to use' guidance, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Формирует отчёт по опросу с фильтрацией (даты, виджеты, теги и др.). Возвращает report_uuid — его можно использовать для чтения файловых и текстовых ответов по виджетам через quiz://{id}/report/{report_uuid}/files и quiz://{id}/report/{report_uuid}/inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Фильтры по тегам. Массив строк — названий тегов (например ["важный", "VIP"]). | |
| dateTo | No | Дата до в формате d.m.Y (например 31.12.2024). | |
| quiz_id | Yes | ID опроса. | |
| widgets | No | Фильтры по ответам на виджеты. Массив объектов {id: widget_uuid, answers: [...]}. Актуальные UUID виджетов — из quiz://{id}/structure. | |
| dateFrom | No | Дата от в формате d.m.Y (например 01.01.2024). | |
| is_complete | No | true = только завершённые ответы (по умолчанию true). | |
| unique_link_ids | No | ID ссылок этого набора: отчёт только по ним. Без unique_link_group_id не учитывается. | |
| unique_link_group_id | No | ID набора уникальных ссылок из manage_quiz_unique_links: отчёт только по ответам этого набора. Работает на любом тарифе. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish it is a non-read-only, non-destructive, non-idempotent generation operation, so describing scope is the lower bar. The description adds real value beyond the annotations by disclosing that the call returns a report_uuid handle and how to consume its outputs via resource URIs — behavior not inferable from the structured fields.
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?
Two dense sentences, front-loaded with the purpose before the return-value/resource detail. No filler. Slightly terse but nothing wasted.
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 an 8-parameter, filter-heavy generation tool with no output schema, the description importantly explains what the call produces (report_uuid) and how to retrieve the actual answers via resource URIs, filling the output-schema gap. Only the concrete filter combinability semantics are left to the schema.
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?
Schema description coverage is 100%, so every parameter (dateFrom/dateTo, widgets, tags, unique_link_ids, etc.) is already documented in the schema. The description only restates the filter categories at a high level, adding no syntax, format, or defaulting detail beyond what the schema provides — the baseline of 3 applies.
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 names a specific verb+resource: forming a filtered quiz report (dates, widgets, tags), and it discloses the return artifact (report_uuid). It clearly distinguishes the tool from read-only siblings like get_quiz_report, but does not explicitly name or contrast with the export_filtered_report_pdf/word or get_quiz_report_* siblings that live nearby.
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?
Usage is implied through the workflow hint (the returned report_uuid feeds the quiz://.../files and /inputs resources), which helps an agent understand the follow-up step. However there is no explicit when-to-use vs when-NOT-to-use guidance, and no routing against the very similar export_filtered_report_* and get_quiz_report* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Отдаёт готовый AI-отчёт по опросу — тот самый, что автор видит в разделе результатов. Отчёт состоит из трёх независимых разделов: текстовый анализ, сравнительный и количественный. У каждого свой статус: готов, строится прямо сейчас или не построен, и почему — мало ответов либо нет подходящих вопросов. Читать отчёт этим инструментом, а не запускать генерацию заново: она тратит лимит тарифа.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the report has three independent sections (textual, comparative, quantitative) each with its own build status and failure reasons (too few responses, no suitable questions). It stops short of describing return format or how partial readiness is surfaced, so not a 5.
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?
The first sentence states what is returned, the second explains the structure, the third explains statuses, and the last gives the routing instruction. Front-loaded and every sentence carries information.
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?
With no output schema, the description valuably pre-announces the return shape (three sections with per-section statuses and reasons), which is what an agent needs to interpret the response. It still doesn't fully specify the response envelope or how statuses are encoded, leaving a small gap.
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?
Only one parameter (quiz_id) and schema coverage is 100%, so the schema fully documents it. The description adds nothing about the parameter's meaning or format, which is the expected baseline when the schema does the work.
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?
Names a specific verb+resource ('Отдаёт готовый AI-отчёт по опросу') and pins down the scope by saying it is the same report the author sees in the results section. It is immediately distinguishable from generate_ai_report in the sibling list.
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?
Explicitly instructs to read the report with this tool rather than re-triggering generation, and states the cost reason (generation consumes the tariff limit). This is a clear when-to-use-this-vs-alternative directive, which is exactly the sibling ambiguity an agent faces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает, какие значения встречались у метки ссылки в ответах этого опроса. Метки цепляют к ссылке (utm_source, идентификатор ученика, номер курса) и они приходят вместе с ответом; по ним отбирают ответы в отчёте. Имена самих меток отдаёт quiz://{id}/hidden_options, а этот инструмент — значения выбранного имени, с поиском и постранично. Отбор по меткам доступен не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Имя метки, например utm_source. Взять из quiz://{id}/hidden_options. | |
| page | No | Страница, с 1. | |
| search | No | Искать среди значений, частичное совпадение. | |
| quiz_id | Yes | ID опроса. | |
| per_page | No | Сколько значений на странице, от 1 до 100. По умолчанию 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: pagination and partial-match search behavior, plus a plan/tariff gating caveat ('Отбор по меткам доступен не на всех тарифах') that an agent needs to anticipate failures.
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?
Front-loads what the tool returns, then explains the label concept, the companion resource, and the tariff caveat. The middle sentence is dense but every clause carries meaning; no filler.
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 5-parameter read tool with no output schema, the description covers return content (values of a label), how to obtain the required key, search/pagination, and the tariff restriction. Only minor gaps remain, such as return ordering or maximum result size.
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?
Schema description coverage is 100%, so key, page, search, per_page and quiz_id are already documented in the schema. The description adds the source of 'key' (hidden_options) and confirms search/pagination semantics, but nothing beyond what the schema already conveys, so the baseline 3 applies.
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?
States a specific verb (показывает, какие значения встречались) and resource (значения метки ссылки в ответах опроса), and clarifies what a 'метка' is with concrete examples (utm_source, идентификатор ученика, номер курса). It separates itself from the sibling get_quiz_hidden_options by explaining that one returns names while this returns values, though it references the resource URI rather than the tool name.
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?
Gives a clear workflow: fetch label names from quiz://{id}/hidden_options first, then call this tool to get the values of the chosen name. It also notes the values can be searched and paginated. It does not state explicit when-not-to-use conditions, keeping it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает теги ответов аккаунта. Читайте перед tag_answer: тот инструмент сопоставляет теги по именам, и без списка вы заведёте новые вместо переиспользования существующих.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds genuine behavioral context by disclosing how tag_answer matches tags by name and the risk of accidental tag creation. It stops short of describing return shape or ordering.
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?
Two tight sentences, front-loaded with what the tool returns and then the reason to call it. No filler; every clause carries selection-relevant information.
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 simple single-parameter read with full annotation coverage and no output schema, the description supplies enough to call it correctly and states what the return represents. Minor gap: no mention of result ordering or volume, but nothing critical is missing.
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?
Single parameter with 100% schema description coverage, so the schema already documents workspace_id and its source (workspace://list). The description adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.
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?
States a specific verb (Возвращает) and resource (теги ответов аккаунта), and explicitly distinguishes itself from the sibling tag_answer by explaining the relationship. An agent can tell it apart from create_answer_tag/delete_answer_tag/tag_answer without opening any schema.
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?
Gives an explicit when-to-use rule: 'Читайте перед tag_answer' and explains the consequence of skipping it (you will create new tags instead of reusing existing ones). This is textbook routing guidance naming the alternative tool and the triggering condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает записи за период: кто записался, на какое время, в каком статусе, кто и почему отменил. В журнале персональные данные респондентов, поэтому он требует того же права, что и остальные результаты.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Конец периода, позже начала. Время без указания пояса считается UTC. | |
| from | Yes | Начало периода. Дата или дата со временем; время без указания пояса считается UTC. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely new context: the journal contains respondents' personal data and therefore requires the same permission as other results — an authorization prerequisite not derivable from 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?
Two sentences, both earning their place: the return payload is front-loaded, followed by the permission constraint. No filler, though it is quite terse for a personal-data-bearing tool.
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?
No output schema exists, and the description compensates by listing the returned fields and flagging the permission requirement. Combined with a fully-covered input schema and read-only annotations, this is close to complete, though it omits pagination/volume behavior for a period query.
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?
Schema description coverage is 100% and each of the three parameters is documented in the schema (UTC handling, workspace_id source). The description only restates the period concept, adding nothing beyond the schema, so the baseline 3 applies.
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?
States a specific verb+resource ('Возвращает записи за период') and enumerates the returned fields (who booked, time, status, who cancelled and why), which distinguishes it from write-side siblings like update_booking or create_booking_block. It does not explicitly name an alternative sibling tool, so it falls short of a 5.
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?
The description implies usage ('за период', requires the same permission as other results) but gives no explicit when-to-use vs when-not guidance and never points to a sibling for a different need. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает библиотеку избранных вопросов аккаунта — вопросы, которые автор переиспользует в разных опросах. В каждой записи лежит снимок вопроса, готовый к передаче в update_quiz_widgets.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that this is an account-level library and that each record is a reusable question snapshot, but does not disclose return format, pagination, or ordering — so with annotations carrying the load, a 3 is appropriate.
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?
Two sentences, front-loaded with what the tool returns, and the second sentence adds the downstream-use detail. It is tight with essentially no filler, though not unusually polished.
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?
No output schema exists, so the description must partially carry return-value burden; it does disclose that each entry holds a question snapshot reusable in update_quiz_widgets. It omits pagination/count/ordering details, keeping it short of fully complete for a list endpoint.
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?
Schema description coverage is 100% and the single workspace_id parameter is already documented in the schema (ID воркспейса из workspace://list). The description adds no syntax, format, or constraint details beyond the schema, so baseline 3 applies.
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 states a specific verb+resource: 'Возвращает библиотеку избранных вопросов аккаунта' (returns the account's library of favorite questions), which is concrete and distinguishable from save_favorite_question/delete_favorite_question. It does not explicitly name a sibling to differentiate against, so it falls short of a 5.
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?
Usage is only implied: it explains the data is 'готовый к передаче в update_quiz_widgets' (ready to pass to update_quiz_widgets), hinting at the fetch-then-apply workflow. There is no explicit when-to-use/when-not statement or named alternative, so it stays at minimum-viable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список папок текущего пользователя.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful scope by clarifying the folders belong to the current user, but it does not disclose return format, ordering, pagination, or whether workspace folders are included. With annotations carrying the safety profile, a 3 is appropriate.
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?
The description is a single, front-loaded sentence with no wasted words. For a simple zero-parameter read tool, this is appropriately sized and immediately communicates the core behavior.
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 zero-parameter, read-only list tool with no output schema and rich annotations, the description covers the essential scope. Minor gaps remain around output shape or pagination, but the structured fields already handle much of the burden.
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 tool takes zero parameters, so there are no parameter semantics to explain. The baseline for 0 params is 4, and no schema descriptions are needed or missing.
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 states a specific verb+resource ('Возвращает список папок') and scopes it to the current user, which distinguishes it from generic folder management. However, it does not explicitly differentiate itself from nearby siblings like create_folder or manage_folder_access, so it falls short of full sibling routing.
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?
There is no explicit when-to-use guidance, no alternative tool named, and no exclusion criteria. The name and description imply a simple read operation, but the agent receives no help choosing this tool over other folder-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает журнал отправки ответов в мессенджер — Telegram или MAX. Это ответ на «заявки не приходят в Telegram»: в журнале виден текст отказа (бота выгнали из группы, чат удалён, токен отозван) и число неотправленных. Журнал вебхуков — отдельный инструмент get_quiz_webhook_logs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Страница журнала, с 1. Записи идут от новых к старым. | |
| quiz_id | Yes | ID опроса. | |
| per_page | No | Сколько записей на странице, от 1 до 200. По умолчанию 20. | |
| integration | Yes | Какой журнал: telegram или max. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by saying what the log actually contains: refusal reasons (bot removed, chat deleted, token revoked) and the count of unsent messages.
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?
Three short sentences, front-loaded with purpose, then the diagnostic value, then the sibling disambiguation. No filler.
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?
No output schema, but the description compensates by describing the return contents (refusal text, unsent count), and the schema fully covers the four inputs. Adequate for an agent to call and interpret it.
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?
Schema description coverage is 100%, with each parameter (page, quiz_id, per_page, integration) already documented including ordering and defaults, so the baseline is 3. The description only surfaces the telegram/max distinction already captured in the enum.
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?
States a specific verb and resource (показывает журнал отправки ответов в мессенджер) with named scope (Telegram или MAX), and explicitly separates itself from the sibling get_quiz_webhook_logs.
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?
Anchors the tool to a concrete diagnostic scenario («заявки не приходят в Telegram») and names the alternative webhook tool, so the agent knows when this is the right read. No explicit exclusion of other situations, but the routing signal is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Состояние e-mail рассылок аккаунта: кампании и их показатели, получатели и что стало с их письмами, списки контактов, шаблоны, репутация отправителя, остаток писем, настройки и журнал отправок. Что именно показать, задаёт section — там же сказано, какой раздел чего требует. Это рассылки по контактным спискам; письма, которые шлёт сам опрос (уведомление автору о новом ответе, копия ответа респонденту), настраиваются другими инструментами — get_quiz_email_settings и соседними. Только чтение: отправить кампанию, править её, списки и шаблоны, покупать письма через ассистента нельзя — письмо уходит живым людям, и отменить его невозможно. Контакты загружают файлом, это тоже вне ассистента.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | За сколько дней считать репутацию. По умолчанию 30. | |
| limit | No | Записей за раз, 1–200. По умолчанию 50. | |
| offset | No | Сколько записей пропустить. | |
| search | No | Поиск: по названию и теме — в campaigns, по адресу — в recipients. | |
| list_id | No | ID списка контактов. Обязателен для contacts. | |
| section | Yes | Что показать. campaigns — список кампаний со сводкой (что отправлено, что в черновиках, что на модерации); campaign — одна кампания с показателями, нужен campaign_id; recipients — получатели этой кампании с фильтрами statuses и quiz_statuses, нужен campaign_id; contact_lists — списки контактов и сводка по ним; contacts — контакты одного списка, нужен list_id; templates — шаблоны писем; reputation — доля отказов и жалоб за период days (по ней почтовые службы решают, пускать ли письма дальше); balance — сколько писем осталось; settings — отправитель и своя почтовая служба; smtp_logs — журнал отправок. Начинайте с campaigns: идентификаторы кампаний берутся оттуда, а списков — из contact_lists. | |
| statuses | No | Статус письма у получателя, для recipients. Значения: sent — отправлено, delivered — доставлено, opened — открыл, clicked — перешёл по ссылке, bounced — не доставлено, unsubscribed — отписался, complaint — пожаловался на спам. У получателя один статус — последнее случившееся событие, поэтому открывшие письмо не попадают в delivered, а перешедшие по ссылке — в opened: чтобы собрать «дошло письмо» целиком, перечислите все нужные значения. Пустой список — все получатели. | |
| campaign_id | No | ID кампании. Обязателен для campaign и recipients. | |
| workspace_id | Yes | ID аккаунта из workspace://list. | |
| quiz_statuses | No | Прохождение опроса получателем, для recipients: none — не начинал, started — начал и не закончил, completed — прошёл до конца. По нему отбирают тех, кому досылать письмо. Пустой список — все. У кампании без привязки к опросу прохождение неизвестно ни у кого, и фильтр вернёт пустой список. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds meaningful boundaries instead — that sending, editing, buying letters and uploading contacts are impossible through the assistant, and why (mail goes to live people and cannot be recalled). This is real context beyond the annotations, though the reason given is somewhat rhetorical.
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?
Front-loaded with the resource and its parts, then boundaries. It is somewhat long, but each sentence carries distinct information (scope, section routing, quiz-email exclusion, read-only/impossibility constraints, file-upload exclusion) rather than padding.
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 multi-section reader with no output schema, the description plus the section enum's own documentation cover what each call returns, how to bootstrap (campaigns then contact_lists) and what is out of scope. Safety is handled by annotations, so nothing critical is missing.
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?
Schema description coverage is 100%, so the schema already documents every parameter (including per-section requirements and enum meanings). The description only points at section ('там же сказано, какой раздел чего требует') without adding format or semantics the schema lacks, so the baseline 3 applies.
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?
States a specific resource (e-mail campaigns of the account) and enumerates exactly what it exposes (campaigns and metrics, recipients and their outcomes, lists, templates, reputation, balance, settings, SMTP log) gated by the section argument. It also explicitly draws the boundary with get_quiz_email_settings and neighbouring tools, so an agent can tell it apart from siblings without opening a schema.
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?
Gives clear context for use and even an ordering hint ('Начинайте с campaigns' since campaign IDs come from there), plus names the alternative tool for quiz-triggered emails. It stops short of fully spelling out when-not-to-use-more-broadly, but the routing advice is concrete rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает партнёрскую статистику текущего пользователя: баланс к выплате и удержанное, список пришедших по партнёрской ссылке с числом их оплат, начисления за период и метки источников. Отвечает на «сколько я привёл и сколько заработал». Только чтение: заявка на выплату и платёжные реквизиты остаются в партнёрском кабинете.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько приглашённых вернуть, по умолчанию 20, максимум 200. | |
| date_to | No | Конец периода в формате ГГГГ-ММ-ДД. | |
| date_from | No | Начало периода в формате ГГГГ-ММ-ДД. Без него берутся все записи. | |
| source_id | No | ID метки источника — показать только пришедших по ней. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds real value beyond that by clarifying the boundary: payout requests and payment requisites are intentionally excluded and remain in the partner dashboard, which prevents the agent from trying to use this tool for a write flow.
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?
Two sentences, front-loaded with the returned payload and followed by the read-only scope caveat. No filler; every clause carries informational weight.
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?
With no output schema, the description compensates by enumerating the returned fields (balance, withheld, referral list, accruals, source labels) and the scope limit. Adequate for an agent to call it correctly, though it does not mention pagination behavior for the referral list.
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?
Schema coverage is 100%, so limit, date_from, date_to, and source_id are already fully documented. The description alludes to the period-based accruals and source labels that these params feed, but adds no syntax or format detail beyond the schema; baseline 3 applies.
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?
States a specific verb+resource ('Возвращает партнёрскую статистику текущего пользователя') and enumerates the returned content: balance payable, withheld, referral list with payment counts, period accruals, and source labels. This lets an agent distinguish it from the mutation sibling manage_partner_source without opening the schema.
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?
Frames the use case clearly ('сколько я привёл и сколько заработал') and scopes it to the current user, and explicitly states what it does not cover (payout request and payment details live in the partner dashboard). It stops short of naming an alternative read tool, but no genuine alternative exists among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает коды конкретного списка промокодов. list_id берётся из get_promocode_list.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Чем сортировать: updated_at — по последнему изменению, name — по самому коду, id — по порядку добавления (по умолчанию). | |
| used | No | Фильтр использованных кодов: 1 — использованные, 0 — неиспользованные. | |
| limit | No | Количество записей (по умолчанию 20). | |
| order | No | Направление сортировки: asc — по возрастанию, desc — по убыванию (по умолчанию). | |
| offset | No | Смещение (по умолчанию 0). | |
| search | No | Искать код по его тексту, частичное совпадение. | |
| list_id | Yes | ID списка промокодов. | |
| quiz_id | No | Отобрать только коды, выданные этим опросом. Не передавать — коды всего списка. | |
| workspace_id | Yes | ID рабочего пространства. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds the data-provenance dependency on get_promocode_list, but says nothing about pagination behavior despite limit/offset parameters, nor about the size or shape of the returned code set.
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?
Two short sentences with zero filler; the core action is front-loaded and the dependency note follows immediately. Nothing to trim.
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 read-only list tool with no output schema, nine parameters and heavy sibling overlap, the description covers the essential identity and the list_id source but omits the return shape (array of codes?) and pagination semantics. Adequate minimum, not complete.
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?
Schema description coverage is 100%, so every one of the nine parameters is already documented in the schema, including enums for sort/order. The description only adds provenance for list_id; it does not explain interaction between filters (e.g., used + quiz_id + search) beyond what the schema says. Baseline 3 applies.
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?
States a specific verb and resource ('Возвращает коды конкретного списка промокодов'), which cleanly separates it from get_promocode_list (returns lists, not codes). The remaining ambiguity is that it doesn't distinguish itself from the sibling get_promocode_list_quizzes, which also returns code-related data.
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?
Gives one concrete prerequisite — list_id comes from get_promocode_list — which is real usage guidance. But it offers no when/when-not guidance relative to the many sibling promocode tools, and doesn't mention that quiz_id filtering or used/search filters exist for narrowing results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает списки промокодов воркспейса. workspace_id берётся из get_workspace_list.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Чем сортировать: updated_at — по последнему изменению, name — по названию, id — по порядку создания (по умолчанию). | |
| limit | No | Количество записей (по умолчанию 20). | |
| order | No | Направление сортировки: asc — по возрастанию, desc — по убыванию (по умолчанию). | |
| offset | No | Смещение (по умолчанию 0). | |
| search | No | Искать список по названию, частичное совпадение. | |
| workspace_id | Yes | ID рабочего пространства. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the workspace-scoping and parameter-provenance context; it says nothing about pagination defaults or result shape, which the annotations do not cover.
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?
Two compact sentences with zero filler, and the core purpose is front-loaded ahead of the dependency hint. Every clause earns its place.
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?
There is no output schema, so the description should ideally explain what a 'promocode list' contains and how it differs from promocode codes, yet it omits return-value context entirely. For a straightforward read-only list tool with full annotation and schema coverage, this is adequate but leaves a real gap.
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?
Schema description coverage is 100%, so all six parameters (sort, limit, order, offset, search, workspace_id) are already documented with defaults and enum meanings. The description's only added value is the provenance of workspace_id, which is marginal over the schema, matching the baseline 3.
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?
States a specific verb and resource ('Возвращает списки промокодов воркспейса'), so the agent knows this fetches promocode lists scoped to a workspace. However, it does nothing to distinguish itself from close siblings like get_promocode_codes or get_promocode_list_quizzes, which an agent must disambiguate by name alone.
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?
The note that 'workspace_id берётся из get_workspace_list' is a useful chaining hint, giving implied context for how to call it. But there is no when-to-use vs when-not guidance and no routing away from the sibling promocode tools, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает, к каким опросам аккаунта привязан список промокодов. Сверху идут привязанные и текущий опрос. Нужен, чтобы не отвязывать вслепую: привязку и отвязку делает manage_promocode_group.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько опросов вернуть, от 1 до 500. По умолчанию 50. | |
| offset | No | Сколько опросов пропустить. | |
| search | No | Искать опрос по названию. | |
| list_id | Yes | ID списка промокодов из get_promocode_list. | |
| quiz_id | Yes | ID опроса, от которого работаем: по нему проверяются права и тариф. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds non-obvious behavior beyond that: result ordering ('Сверху идут привязанные и текущий опрос'), which an agent would otherwise have to discover empirically. It stops short of describing pagination or totals.
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?
Three short sentences, front-loaded with the purpose, then the ordering note, then the routing hint. Every sentence carries information, though the ordering sentence could be merged without loss.
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 read-only list tool with full annotation coverage and fully described parameters, the description supplies the one thing structured fields cannot: the relationship semantics and result ordering. No output schema exists, but the description signals the return nature well enough.
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?
Schema description coverage is 100%, so limit, offset, search, list_id and quiz_id are already documented in the schema. The description adds no syntactic or semantic detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource: shows which account quizzes a promocode list is linked to. It clarifies the relationship direction (list → quizzes) and implicitly distinguishes itself from the mutation sibling manage_promocode_group. An agent can tell what it returns without opening the schema.
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?
Explicitly names the alternative and the condition: 'Нужен, чтобы не отвязывать вслепую: привязку и отвязку делает manage_promocode_group.' This tells the agent to read here and mutate there, removing all inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список ответов респондентов (submissions) по опросу. Каждый ответ содержит answer_id для toggle_answer_visibility и tag_answer.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Фильтр по дате (формат Y-m-d). | |
| sort | No | Поле сортировки: date_end или date_start. | |
| limit | No | Количество ответов (по умолчанию 20, макс. 100). | |
| order | No | Направление сортировки: asc или desc. | |
| offset | No | Смещение (по умолчанию 0). | |
| quiz_id | Yes | ID опроса. | |
| is_deleted | No | Скрытые ответы: true — показать те, что исключены из отчётов. По умолчанию их в выдаче нет. | |
| is_complete | No | Фильтр по завершённости (true — только завершённые, false — незавершённые). | |
| is_screenout | No | Отсеянные ответы: true — показать тех, кого отсеяла логика опроса. По умолчанию их в выдаче нет. | |
| unique_link_ids | No | ID ссылок этого набора: только их ответы. Без unique_link_group_id не учитывается. | |
| unique_link_group_id | No | ID набора уникальных ссылок из manage_quiz_unique_links: только ответы этого набора. Работает на любом тарифе. У каждого ответа в выдаче есть поле unique_link — ссылка и набор или null. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds useful response context by stating each answer carries an answer_id consumed by toggle_answer_visibility and tag_answer, but says nothing about pagination behaviour or result shape beyond that one field.
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?
Two tight sentences with the core purpose front-loaded and no filler. It could be even leaner given how much the schema already carries, but nothing is wasted.
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 read-only list tool with full annotation coverage and complete parameter documentation, this is minimally adequate. With no output schema, a little more on the returned structure and how to page through large answer sets would help, but the essential calling information is present.
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?
Schema description coverage is 100% and 11 parameters (including filters, sort, limit/offset, and link-scoping fields) are all documented in the schema. The description adds no parameter meaning beyond what the schema already provides, so the baseline 3 applies.
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?
States a specific verb + resource: returns a list of respondent answers (submissions) for a quiz. The purpose is unambiguous, but it never differentiates itself from adjacent siblings such as get_answer_tags, get_answer_extra_field_values, or the export_answers_* family, which also surface answer data.
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 when-to-use, when-not-to-use, or alternative-tool guidance is given. The mention of answer_id feeding toggle_answer_visibility and tag_answer hints at downstream workflows, but that is a data-flow note rather than selection guidance against the many sibling answer/report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Справочники CRM и текущее сопоставление полей: что вообще уходит в amoCRM или Bitrix24 и в какие поля. Отдаёт то же, что видит человек в форме настройки — поля лида, сделки, контакта и компании, воронки со стадиями, ответственных, типы, — и рядом сопоставление, уже сохранённое у опроса. Только чтение: менять сопоставление нельзя, его форму задаёт доставка заявок, и блок не той формы молча ломает отправку — правят его в кабинете. Справочники читаются живыми запросами в CRM, поэтому вызов не мгновенный и вернёт отказ, если доступ к порталу отозвали.
| Name | Required | Description | Default |
|---|---|---|---|
| crm | Yes | Какая CRM: amocrm или bitrix24. | |
| quiz_id | Yes | ID опроса. | |
| sections | No | Какие справочники нужны: lead, deal, contact, company, users, pipelines, types. По умолчанию lead и contact — каждый справочник это отдельный запрос в CRM. | |
| deal_category_id | No | Номер воронки сделки: стадии принадлежат воронке, и без него портал отдаёт стадии воронки по умолчанию. Только для Bitrix24. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: it explains that changing mappings is not allowed and that altering the block form can silently break delivery, that reference data is fetched live from CRM (non-instant), and that access revocation leads to failure. These details go well beyond the readOnly and openWorld hints.
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?
The description is a single, well-structured paragraph that front-loads the purpose and then adds constraints and behavior. It is informative but slightly lengthy; every sentence earns its place by covering distinct aspects (purpose, read-only nature, live fetch, failure mode).
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?
Given no output schema, the description fully explains what data is returned (references and mapping), the read-only nature, the live-fetch latency and failure conditions, and that the shape is determined by delivery settings. This is sufficient for an agent to call the tool correctly.
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?
Schema coverage is 100% and each parameter has a description, so the schema already documents crm, quiz_id, sections, and deal_category_id. The description does not add syntax or format details beyond what the schema provides, so a baseline 3 is appropriate.
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 explicitly states what the tool returns: CRM reference data and the currently saved field mapping for amoCRM or Bitrix24. It names the exact entities (lead, deal, contact, company, pipelines, users, types) and distinguishes itself from sibling write tools like manage_quiz_crm_mapping by emphasizing it is read-only and shows what is already saved.
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?
The description clearly implies when to use it: to inspect current CRM fields and mappings before configuring delivery. It states that changes must be made elsewhere ('правят его в кабинете'), effectively directing to a different interface, though it does not name a sibling tool like manage_quiz_crm_mapping explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает настройки писем опроса: включены ли уведомление автору и копия респонденту, список адресов автора с их состоянием подтверждения и шаблоны писем. Адрес работает только после подтверждения по ссылке из письма — это поле «checked».
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe read-only, idempotent, non-destructive operation, so the bar is lower. The description adds useful domain behavior by explaining that an author address only works after confirmation via email and that the "checked" field reflects this state, which is not captured by annotations or schema.
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?
Two tight sentences: the first front-loads the return contents, and the second adds a critical domain rule about address confirmation. Every clause earns its place, with no repetition or filler.
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 simple one-parameter read tool with no output schema, the description adequately explains the return shape by naming the settings categories and the confirmation-state field. Combined with rich annotations covering safety semantics, an agent has enough context to call it correctly.
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?
There is a single required parameter, quiz_id, and schema description coverage is 100% with the description "ID опроса." The tool description adds no further parameter meaning, so the baseline of 3 is appropriate when the schema already documents the parameter.
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 states a specific verb ("Возвращает") and resource ("настройки писем опроса") and enumerates the exact settings returned: author notification, respondent copy, author address confirmation states, and email templates. This clearly distinguishes it from sibling mutation tools such as add_quiz_email_recipient, confirm_quiz_email_recipient, and save_quiz_email_template.
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?
The description explains what the tool returns but gives no when-to-use guidance, no prerequisites, and no explicit alternatives among the many sibling tools. An agent must infer that this is the read-only counterpart to the email recipient and template management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает, куда опрос отправляет ответы кроме почты: Telegram, MAX, AmoCRM, Битрикс24, Zapier, Google Таблицы. По каждой видно, подключена ли она, включена ли отправка и разрешает ли её тариф. Отвечает на «почему заявки не приходят в CRM». Только чтение: подключение — это вход в чужой аккаунт или ввод токена. Вебхуки живут отдельными инструментами, начните с get_quiz_webhooks.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered, but the description adds genuine context: it explains why there is no write counterpart here (connecting means logging into a third-party account or entering a token) and what per-integration status is exposed (connected / sending enabled / tariff-allowed). This is useful behavioral detail beyond 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?
The purpose is front-loaded in the first sentence, followed by what each integration shows, the diagnostic value, and the sibling routing. Every sentence earns its place with no filler.
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?
Even without an output schema, the description discloses what is returned per integration (connection state, send-enabled state, tariff permission) and why it exists. Nothing needed to call it correctly is missing.
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?
Schema description coverage is 100% for the single required quiz_id parameter, so the schema already carries the parameter meaning. The description adds no format or semantics beyond that, which is the correct baseline when the schema does the work.
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 states a specific verb and resource ('показывает, куда опрос отправляет ответы') and enumerates the exact integration channels (Telegram, MAX, AmoCRM, Битрикс24, Zapier, Google Таблицы). It explicitly distinguishes itself from get_quiz_webhooks, so an agent can tell it apart from the closest sibling.
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?
It gives a concrete diagnostic use case ('почему заявки не приходят в CRM') and explicitly routes webhook-related questions to a named sibling ('вебхуки живут отдельными инструментами, начните с get_quiz_webhooks'). This is explicit when-to-use plus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список опросов аккаунта. Без параметров — все живые опросы. Можно искать по названию, смотреть отдельную папку, ограничить список одним форматом и открыть архив: архивные опросы в обычный список не попадают. У каждого опроса виден признак is_archived и формат type: regular — обычный опрос со своей страницей, micro — опрос на сайте, он показывается карточкой внутри чужой страницы, и своей ссылки для респондента у него нет.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Искать по названию, частичное совпадение без учёта регистра. | |
| type | No | Показать только опросы одного формата: regular — обычные, micro — опросы на сайте. Без параметра приходят оба. | |
| limit | No | Сколько опросов вернуть, от 1 до 200. | |
| offset | No | Сколько опросов пропустить. | |
| archived | No | true — показать архивные вместо обычных. По умолчанию false. | |
| folder_id | No | Показать только опросы этой папки (folder://list). | |
| workspace_id | No | ID аккаунта из workspace://list. Без него список собирается по всем аккаунтам, к которым есть доступ, — и своим, и тем, куда вас пригласили. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only idempotent operation, and the description adds real behavior: archived surveys are excluded from the normal list, each item carries is_archived and type, and workspace_id defaults to all accessible accounts including invited ones. This exceeds the annotation coverage.
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?
Front-loaded with the core purpose and then enumerates capabilities efficiently in one dense passage. The regular/micro distinction is explained twice (in the description and the schema), creating mild redundancy.
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?
With no output schema, the description usefully discloses return-item fields (is_archived, type) and default scoping, which is what an agent needs. It could mention pagination interplay between limit/offset more explicitly, but coverage is solid for a read tool.
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?
Schema description coverage is 100%, so every parameter is already documented, giving a baseline of 3. The description restates the type enum and archive behavior but adds little parameter detail beyond what the schema provides.
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?
States a specific verb and resource ('Возвращает список опросов аккаунта') and defines the default scope (all live surveys). It is clearly distinguishable from siblings like get_quiz_structure or get_quiz_answers, but it never names an alternative list-like sibling to sharpen that boundary.
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?
Describes concrete usage contexts: no params returns all live surveys, and name/folder/type/archive filters each have a stated purpose. Missing an explicit 'when not to use' or a named alternative, 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.
Возвращает детальный отчёт по виджетам опроса. Поддерживает фильтрацию по завершённости и датам. Возвращает report_uuid, который нужен для get_quiz_report_files и get_quiz_report_inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | Конец периода (формат Y-m-d). | |
| quiz_id | Yes | ID опроса. | |
| date_from | No | Начало периода (формат Y-m-d). | |
| is_complete | No | Только завершённые ответы (по умолчанию true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read profile (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the bar is lower. The description adds genuinely new behavioral context: it names the returned artifact (report_uuid) and discloses that this identifier is a required input for two sibling tools, which is workflow information found nowhere in the schema or 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?
Three short sentences with the core action front-loaded, then filtering capability, then the downstream dependency. No filler, no repetition of the tool name, and every sentence carries information the agent needs.
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 read-only report tool with full schema coverage and no output schema, the description covers purpose, filters, and the key output token plus its consumers. The remaining gap is the relationship to report-generation siblings (generate_filtered_report, generate_ai_report) — it is unclear whether this tool produces a report or only retrieves an existing one.
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?
Schema description coverage is 100%, so date_from, date_to, quiz_id and is_complete are already fully documented, including the default for is_complete. The description only restates the filter dimensions at a high level and adds no format or edge-case detail, so the baseline 3 applies.
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 states a specific verb and resource ('Возвращает детальный отчёт по виджетам опроса'), so the agent knows it returns a per-widget report rather than raw answers or a summary. It does not explicitly contrast itself with adjacent report tools such as get_quiz_summary or generate_filtered_report, so the differentiation is partial rather than sharp.
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?
Usage is implied: filtering by completion status and date range, plus a clear downstream dependency chain pointing to get_quiz_report_files and get_quiz_report_inputs. However, there is no explicit statement of when to prefer this over get_quiz_summary, get_quiz_report_filters, or the generate_* report tools, and no stated prerequisites (e.g. whether a report must be generated first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает файловые ответы (загруженные файлы) для конкретного виджета из отчёта. report_uuid берётся из get_quiz_report; widget_id и widget_hash — из get_quiz_structure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Количество записей (по умолчанию 50). | |
| offset | No | Смещение (по умолчанию 0). | |
| quiz_id | Yes | ID опроса. | |
| widget_id | Yes | UUID виджета из get_quiz_structure. | |
| report_uuid | Yes | UUID отчёта из get_quiz_report. | |
| widget_hash | Yes | Hash виджета из get_quiz_structure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds no behavioral context beyond that: nothing about how paging interacts with results, whether files can be missing/expired, or any access requirements.
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?
Two short sentences, front-loaded with what is returned and followed by where the required identifiers come from. No filler, no restating of the tool name.
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?
There is no output schema, so the description should ideally sketch the return shape (file entries, URLs, pagination via limit/offset), but it stops at naming the resource. Safety is covered by annotations and all six parameters are documented in the schema, so it is adequate but incomplete for a no-output-schema tool.
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?
Schema description coverage is 100%, including the same provenance notes ('UUID виджета из get_quiz_structure'), so the description largely repeats structured data. The baseline of 3 applies; no additional meaning such as default paging semantics or widget scope is added.
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 states a specific verb and resource ('Возвращает файловые ответы (загруженные файлы)') scoped to a specific report widget, which cleanly separates it from text-oriented siblings like get_quiz_answers and the report-level get_quiz_report. An agent can identify exactly what this returns without opening the schema.
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?
It gives a useful prerequisite chain — report_uuid from get_quiz_report, widget_id/widget_hash from get_quiz_structure — which implies the usage workflow. However, it never says when to prefer this over sibling answer-retrieval tools such as get_quiz_answers, nor any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает сохранённые фильтры пользователя для отчётов опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, destructiveHint=false, so safety is fully covered. The description adds the object of retrieval (user's saved report filters) but omits return format, pagination, or auth context, adding modest value beyond structured fields.
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?
A single clear sentence with no filler, front-loading the verb and the returned resource. Nothing can be removed without losing meaning.
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 low-complexity, one-parameter, read-only tool with full annotation coverage and no output schema, the description is nearly sufficient. The only gap is that it doesn't state what the saved filters contain or how they relate to report generation, but an agent can call the tool correctly.
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?
Schema coverage is 100%, and quiz_id is described in the schema as 'ID опроса.' The description adds no additional syntactic or semantic detail about the parameter, so the baseline 3 applies.
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?
States a specific verb ('Возвращает' = returns) and resource ('сохранённые фильтры пользователя для отчётов опроса'). It is distinguishable from save_quiz_report_filters by the read verb, but it does not explicitly name any sibling or scope limits.
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?
Provides no when-to-use, prerequisites, or alternatives. An agent must infer from the name that this is the read counterpart to save_quiz_report_filters; the description itself offers no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает текстовые ответы (input-виджеты) для конкретного виджета из отчёта. report_uuid берётся из get_quiz_report; widget_id и widget_hash — из get_quiz_structure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Количество записей (по умолчанию 50). | |
| offset | No | Смещение (по умолчанию 0). | |
| quiz_id | Yes | ID опроса. | |
| widget_id | Yes | UUID виджета из get_quiz_structure. | |
| report_uuid | Yes | UUID отчёта из get_quiz_report. | |
| widget_hash | Yes | Hash виджета из get_quiz_structure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds the useful framing that these are input-widget answers, but says nothing about pagination behavior or result volume despite the limit/offset parameters, so it only modestly exceeds the annotation baseline.
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?
Two sentences, front-loaded with the purpose and followed by the parameter-sourcing rule. No redundant restatement of the name, title, or schema, and every clause earns its place.
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 read-only tool with full schema coverage, no output schema, and safety annotations, the description is nearly complete: it explains what is returned and where the identifiers come from. It omits any note on how limit/offset paginate the results, which is the one remaining gap.
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?
With 100% schema description coverage the baseline is 3. The description adds cross-referential meaning beyond the schema by specifying that report_uuid originates from get_quiz_report and widget_id/widget_hash from get_quiz_structure, clarifying the provenance and dependency of the required params.
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?
States a specific verb ("Возвращает") and a precisely scoped resource: text answers / input-widgets for a specific widget within a report. This clearly separates it from broad siblings like get_quiz_answers or get_quiz_report, so an agent can distinguish it without opening the schema.
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?
Explicitly tells the agent where the required identifiers come from (report_uuid from get_quiz_report, widget_id/widget_hash from get_quiz_structure), which is genuine routing guidance between dependent tools. It stop short of naming an explicit exclusion or contrasting with get_quiz_answers, so it is a strong 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает структуру опроса: ids (порядок виджетов), entities (конфиги виджетов), hidden options. Используйте перед update_quiz_widgets и update_quiz_logic.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint false, and destructiveHint false, so the safety profile is fully covered. The description adds the useful note that hidden options are included and the intended use as a read-before-write step, but does not disclose return format or pagination, so it adds moderate value on top of structured data.
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 sentence plus one usage sentence, front-loaded with the action and its return contents. Every clause earns its place with no filler.
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 single-parameter read tool with rich annotations and no output schema, the description covers purpose, returned fields, and workflow placement. It could briefly note that no output schema exists or what the return shape looks like, but it is largely complete.
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?
Schema description coverage is 100% with a single required quiz_id parameter, so the schema already documents the input. The description adds no parameter-level syntax or format details beyond what the schema provides, making the baseline 3 appropriate.
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 clearly states a specific verb and resource: it returns the quiz structure and enumerates the three components (ids/order, entities/widget configs, hidden options). This distinguishes it from siblings like get_quiz_widgets_hidden or get_quiz_hidden_options, though it doesn't explicitly name them as alternatives.
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?
It explicitly states when to use it: before update_quiz_widgets and update_quiz_logic. That is a precise, actionable workflow instruction that tells the agent both the context and the downstream consumers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает сводную аналитику опроса: визиты, устройства, география и другие метрики. У опроса на сайте (формат micro) ответ другой формы: признак quiz_type, is_connected и воронка показов на чужой странице — показы, открытия, начатые и завершённые прохождения, отказы и причины, по которым опрос не показали. При is_connected = false опрос ещё не подключён ни к одному сайту, и показов не было.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, non-destructive read. Beyond that, the description adds genuine behavioral context: the response shape differs for site-hosted (micro) quizzes, exposes a quiz_type marker and is_connected flag, and explains that is_connected = false means the quiz is not yet attached to any site and has produced no impressions. That last point meaningfully prevents misreading a zeroed funnel.
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?
The description is front-loaded with the core purpose before branching into format-specific detail, and every sentence carries information. It is dense but not padded, though the micro-format conditional is packed into one long clause that could be split for readability.
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?
There is no output schema, so the description must carry return-value meaning — and it does, naming the main metric groups and the alternate funnel fields (impressions, opens, starts, completions, refusals). An agent knows what to expect back, which is the main risk for a no-output-schema analytics tool.
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?
With a single parameter and 100% schema description coverage, the schema already fully documents quiz_id. The description adds no syntax, format, or constraint information for the parameter, so the baseline of 3 applies.
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 states a concrete verb and resource — it returns summary analytics (visits, devices, geography) for a quiz — and enumerates the actual metric families returned. It is clear enough to distinguish from generic obfuscated read tools, though it never names the closest siblings (get_quiz_report, export_summary_pdf, share_summary_link), so differentiation from those is left to inference.
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?
There is no explicit statement of when to choose this over get_quiz_report, get_ai_report, or export_summary_pdf, and no prerequisites are given. The conditionals present (micro format changes the response shape) describe output variance, not usage selection, so the agent gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает стандартные и пользовательские надписи (тексты) опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Язык служебных надписей: ru, en и прочие. По умолчанию — язык самого опроса. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds the fact that both standard and custom texts are returned, but says nothing about pagination, return shape, or localization fallback behavior beyond the schema.
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?
A single efficient sentence that is front-loaded with the verb and resource. No filler, though it is too terse to carry much additional value.
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 simple read-only lookup with full schema coverage and complete annotations, the description is adequate. No output schema exists, so no return-value explanation is owed, though the description could have mentioned localization behavior.
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?
Schema description coverage is 100%, so both quiz_id and the lang default ('По умолчанию — язык самого опроса') are already documented in the schema. The description adds no parameter-level meaning beyond this, so baseline 3 applies.
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?
States a specific verb ('Возвращает') and resource ('надписи (тексты) опроса') with scope ('стандартные и пользовательские'), which distinguishes it from the write sibling update_quiz_texts by verb alone. It does not explicitly name that sibling, but the read/write split is inferable.
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 guidance on when to use this versus update_quiz_texts or other get_* tools; no mention of prerequisites or context. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает скрытые переменные опроса (UTM / extra_fields).
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe-read profile is covered. The description adds only that the variables are 'hidden' and UTM/extra_fields-related; it says nothing about permissions, return shape, or volume beyond that.
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?
A single, front-loaded clause with no wasted words; the essential scope is stated immediately. It is efficient, if slightly terse.
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 simple read getter with full annotation coverage and full parameter documentation, little is missing. However, with no output schema, the description could hint at the returned variable structure (keys, UTM vs extra_fields shape), which it does not.
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?
Only one parameter (quiz_id) with 100% schema description coverage, so the schema already documents it fully. The description adds no further syntax or format detail, which is the correct baseline of 3 when the schema does the work.
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?
States a specific verb (Возвращает/Returns) plus the resource (скрытые переменные опроса) and clarifies the content with concrete examples (UTM / extra_fields). This distinguishes it from a plain field getter, though it does not explicitly contrast with the nearby sibling get_quiz_hidden_options.
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 guidance on when to use this versus alternatives such as get_quiz_hidden_options or get_quiz_crm_fields, and no prerequisites stated. The agent must infer the context entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает историю публикаций опроса: каждая публикация оставляет снимок. Черновик в список не попадает — это текущее состояние, а не история. Снимок с is_live — тот, который сейчас видят респонденты. По version_id из этого списка работает restore_quiz_version.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько снимков вернуть, от 1 до 100. По умолчанию 20. | |
| offset | No | Сколько снимков пропустить от начала списка. Список отсортирован от новых к старым. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful semantic context: each publication creates a snapshot, drafts are excluded, and is_live marks the snapshot currently visible to respondents. It also connects the output version_id to restore_quiz_version, which is valuable behavioral information beyond 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?
The description is four sentences, front-loaded with the tool's purpose. Every sentence adds distinct value: what the tool shows, why drafts are excluded, what is_live means, and how the output relates to restore_quiz_version. There is no redundancy or filler.
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?
Given a fully documented schema and clear annotations, the description covers the essential semantics of the returned data (snapshots, exclusion of drafts, meaning of is_live). It does not describe all possible fields in the snapshot list, but without an output schema the description provides enough context for an agent to understand the tool's result and usage. Minor gaps in return format detail are acceptable.
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?
Schema description coverage is 100%, so the input schema fully documents quiz_id, limit, and offset, including ranges and default values. The description adds no additional parameter details, which is acceptable given the schema's completeness, but it does not compensate for anything because there is nothing to compensate for.
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 states a specific verb and resource: 'Показывает историю публикаций опроса' (shows quiz publication history). It distinguishes the tool from related operations by explaining that drafts are not included and that snapshots are historical versions, not the current state. This clearly separates it from siblings like get_quiz_structure or get_quiz_summary.
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?
The description implies when to use it: to view publication history and to obtain version_id for restore_quiz_version. It also gives an exclusion: drafts are not listed because they are the current state, not history. However, it does not explicitly name an alternative tool for accessing the current draft state, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает журнал отправок вебхука: дошла ли отправка и что ответил приёмник — код ответа и тело. Это единственный способ ответить на «почему данные не приходят»: по самой настройке вебхука этого не видно.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Номер страницы, по умолчанию 1. | |
| quiz_id | Yes | ID опроса. | |
| per_page | No | Записей на странице, по умолчанию 20, максимум 30. | |
| webhook_id | Yes | ID вебхука (из get_quiz_webhooks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value: it discloses the content of the return payload (delivery outcome, response code and receiver body), which annotations do not convey.
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?
Two sentences with no padding; the main purpose is front-loaded and the diagnostic use case follows as a rationale rather than filler.
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 read-only, no-output-schema tool whose parameters are fully self-documented, the description covers purpose, return content, and usage context. Pagination behavior is left to the schema, which is a minor acceptable gap.
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?
Schema description coverage is 100%, so all four parameters (page, per_page, quiz_id, webhook_id) are already documented in the schema, including defaults and the max of 30. The description adds no parameter-level detail, so the baseline of 3 applies.
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?
States a specific verb and resource ('возвращает журнал отправок вебхука') and immediately clarifies what the log contains (delivery status, response code and body). The closing clause contrasts it with the webhook configuration tool, so an agent can distinguish it from the sibling get_quiz_webhooks without opening either schema.
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?
Gives a clear triggering scenario — diagnosing 'почему данные не приходят' — and notes that the webhook setting itself won't reveal this. It does not explicitly name alternative tools (get_quiz_webhooks, resend_quiz_webhook_log, get_integration_logs), but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает вебхуки опроса и их состояние: адрес, метод, включён ли вебхук и не отключился ли он сам после серии неудачных отправок. Идентификаторы вебхуков приходят только отсюда — читайте список перед любой правкой.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it discloses that webhooks can self-disable after repeated failed sends and that IDs are only obtainable here, which shapes how the agent must sequence a later mutation. No pagination or volume details, keeping it at 4.
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?
Two tightly packed sentences with zero filler. The return-value content comes first and the usage directive ('read before any edit') is front-loaded as the closing imperative, so an agent gets purpose and sequencing in one read.
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 read-only list tool whose annotations already carry the safety profile, the description covers purpose, returned fields, a non-obvious behavioral trait (auto-disable), and invocation guidance. No output schema exists, yet the description summarises the return shape, so nothing critical is missing.
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?
Schema description coverage is 100% and there is a single parameter (quiz_id), so the schema already carries the parameter semantics. The description adds no format or scoping nuance for quiz_id, so the baseline 3 applies.
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?
States a specific verb (возвращает) and resource (вебхуки опроса) and enumerates the returned state fields: address, method, enabled status, and auto-disable after failed sends. An agent can distinguish this from get_quiz_webhook_logs and the create/update/delete/toggle webhook siblings without opening the schema.
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?
Explicitly tells the agent when to reach for this tool: 'идентификаторы вебхуков приходят только отсюда — читайте список перед любой правкой,' which is a clear precondition for any edit. It does not name a specific alternative (e.g. get_quiz_webhook_logs for delivery history), so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Заказанные респонденты: кампании закупки прохождений и их результат. Без campaign_id — список кампаний аккаунта с ценой одного ответа и минимальным размером группы. С campaign_id — карточка кампании: статус и модерация, просмотры, ответы, конверсия, первое и последнее прохождение, среднее время, социально-демографические параметры заказа (названия городов уже подставлены) и данные об оплате. Только чтение: заказать кампанию и оплатить её через ассистента нельзя, это списание денег. Расчёт доступной аудитории по соцдему тоже делают в кабинете.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | No | ID кампании из списка. Без него приходит список кампаний. | |
| workspace_id | Yes | ID аккаунта из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: the rationale (ordering would mean spending money), and the fact that audience estimation is intentionally out of scope. It does not cover pagination or rate limits.
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?
Well front-loaded: purpose first, then the two modes, then the boundaries. Slightly dense in the campaign-card enumeration (views, answers, conversion, timings, socdem, payment), but every element describes a return field that matters given there is no output schema.
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?
With no output schema, the description carries the full burden of describing returns, and it does so for both branches — list fields (price per answer, minimum group size) and card fields (status, moderation, views, answers, conversion, first/last completion, average time, socdem, payment). Nothing essential to calling it correctly is missing.
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?
Schema coverage is 100% and both parameters are documented in the schema, including the 'without it you get the list' behavior of campaign_id. The description's mode split reinforces but does not add syntax or constraints beyond what the schema already provides, so the baseline 3 applies.
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?
States a specific resource (respondent campaigns / purchased survey completions) and spells out both operating modes: list-of-campaigns without campaign_id, detailed campaign card with campaign_id. No sibling in the list does anything similar, so the agent can distinguish it immediately.
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?
Explicitly bounds the tool: read-only, ordering and paying for a campaign cannot be done through the assistant, and the available-audience-by-socdem calculation is done in the cabinet. This tells the agent when NOT to reach for it, though it does not name a specific alternative tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает расписания записи на встречи: рабочие часы или слоты вручную, длительность встречи, буферы, лимиты и способ подтверждения. Расписание живёт на уровне аккаунта и подключается к опросам отдельно, поэтому одно расписание может обслуживать несколько опросов. Идентификаторы расписаний приходят только отсюда.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: schedules live at the account level, connect to quizzes separately, and are shared across multiple quizzes, plus that IDs originate only here. Return value shape is not described, keeping it out of the top band.
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?
Three sentences, front-loaded with what the tool returns, followed by scope and ID-sourcing notes. Each sentence contributes distinct information with no filler, though the structure is a dense block rather than strictly prioritized.
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?
With no output schema, the description compensates by listing the returned schedule attributes and the account-level relationship that governs how schedules are reused. Pagination or result-volume behavior is not addressed, leaving a small gap for a list-style getter.
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?
Schema description coverage is 100% for the single workspace_id parameter (documented as 'ID воркспейса (из workspace://list)'), so the schema carries parameter meaning. The description adds no syntax or sourcing detail beyond that, making the baseline 3 appropriate.
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?
States a specific verb ('Возвращает') and resource ('расписания записи на встречи') and enumerates what a schedule contains (working hours or manual slots, duration, buffers, limits, confirmation method). An agent can distinguish this getter from the sibling save_scheduler/delete_scheduler/duplicate_scheduler tools without opening any schema.
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?
The clause 'Идентификаторы расписаний приходят только отсюда' gives a clear reason to call this tool (to obtain schedule IDs), and the account-level/quiz-attachment explanation clarifies scope. It does not explicitly name the alternative scheduler tools or state when not to use it, so it falls just short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает все тарифы с ценами, периодами и тем, что в них входит. Нужен, когда упёрлись в «недоступно на текущем тарифе»: по этому списку видно, какой тариф решает задачу. Цены считаются с учётом текущего тарифа аккаунта — доплата при переходе уже учтена. Только чтение: оплатить или сменить тариф через ассистента нельзя, это решение человека.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real context beyond them: prices are computed relative to the account's current tariff and any upgrade surcharge is already included, and it clarifies the assistant cannot pay or switch (human decision). The 'read-only' statement partially restates readOnlyHint, keeping it out of 5 territory.
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?
Four tight sentences, front-loaded with what the tool returns before the usage trigger and behavioral caveats. Nothing is wasted, though the pricing sentence is slightly dense for a single-scope read tool.
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 simple read-only listing tool with no output schema, the description fully covers what is returned (tariffs, prices, periods, inclusions), the case for calling it, the pricing semantics, and the action limitation. An agent has everything needed to call it correctly.
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?
Schema description coverage is 100% and the single workspace_id parameter is documented in the schema (including how to obtain it). The description adds no additional parameter meaning, so the baseline 3 applies.
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?
States a specific verb and resource ('Показывает все тарифы') plus the payload the agent will receive (цены, периоды, что входит). It also implicitly distinguishes itself from the sibling get_workspace_tariff by being the full catalog rather than the current plan.
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?
Gives a concrete trigger condition — use it when you hit 'недоступно на текущем тарифе' — which is exactly the decision context an agent needs. It does not explicitly name a sibling alternative (e.g. get_workspace_tariff) for comparison, 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.
Возвращает детальные настройки темы оформления (цвета, фон, кнопки и др.).
| Name | Required | Description | Default |
|---|---|---|---|
| theme_id | Yes | ID темы. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the nature of the payload (colors, background, buttons), which is useful given no output schema, but discloses nothing about permissions, error cases, or pagination.
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?
A single efficient sentence with the verb front-loaded. The parenthetical example list ('цвета, фон, кнопки и др.') is mildly redundant but does add useful signal about return content, so it earns its place.
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 single-parameter, read-only getter fully covered by annotations and schema, the description is adequate; it also hints at return content in the absence of an output schema. It is somewhat thin on how theme_id is obtained and how this differs from get_theme_list.
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?
Schema description coverage is 100%, so theme_id is already documented as the theme ID. The description adds no syntax or format detail beyond the schema. Baseline 3 is appropriate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Возвращает) and resource (детальные настройки темы оформления), and clarifies it returns detailed settings of a single theme, which implicitly distinguishes it from get_theme_list. It does not explicitly name the listing sibling, so an agent must infer the single-vs-list distinction.
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?
There is no explicit guidance on when to use this tool versus get_theme_list, create_theme, update_theme, or apply_quiz_theme. The description only states what it returns, leaving the agent to infer that a theme_id must already be known (e.g., from get_theme_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список тем оформления, доступных текущему пользователю.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds that results are scoped to what the current user can access, which is useful permission context, but it says nothing about ordering, pagination, or whether built-in themes are included.
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?
A single front-loaded sentence that conveys the resource and its scope with no filler. It is appropriately sized for a no-argument list endpoint, though it stops short of any additional value.
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 zero-parameter read-only list tool whose safety traits are already in annotations, the description covers the essentials. The lack of output schema means it could optionally describe what a theme entry contains, but nothing critical for correct invocation is missing.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter semantics are needed or missing.
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?
States a specific verb ("Возвращает") and resource ("список тем оформления") plus a scope qualifier ("доступных текущему пользователю"). It is clearly distinct from create_theme/update_theme/manage_theme, but it does not explicitly differentiate itself from the sibling get_theme_details.
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?
The description only says what is returned; it gives no when-to-use guidance and never names the alternative get_theme_details for per-theme lookups. Usage must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает информацию о текущем авторизованном пользователе (ID, email, язык, рабочее пространство) и его права по каждому рабочему пространству (workspaces[]: is_owner, role, access, folder_access, blocked). Читайте до действий: по access видно, что разрешено, без пробных вызовов.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already fully declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description adds the payload semantics of permissions (access, blocked, is_owner) but says nothing about authentication requirements, error behavior when unauthorized, or rate limits. Useful but not rich behavioral context.
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?
Two sentences, well front-loaded with the core return content before the operational advice. Slightly dense with parenthetical field enumerations, but every clause carries information and nothing is wasted.
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?
With no output schema, the description compensates by enumerating the returned identity fields and the nested workspaces[] rights structure, and annotations cover the safety profile. For a zero-parameter, low-complexity identity tool this is sufficient for an agent to call it correctly.
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 tool takes zero parameters, so there is no parameter surface for the description to clarify; the baseline of 4 applies. No misleading param claims are made.
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?
States a specific verb and resource ("Возвращает информацию о текущем авторизованном пользователе") and enumerates the returned fields plus the per-workspace rights array. No sibling tool returns the current user identity, so the tool is unambiguously distinguishable despite the shared "get_*" prefix.
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?
"Читайте до действий: по access видно, что разрешено, без пробных вызовов" gives clear when-to-use guidance and a rationale (avoid trial calls), which is valuable in a large sibling set. It stops short of naming an explicit alternative or a when-not-to-use condition, so it does not reach 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Рассказывает, что это за аккаунт и что в нём можно владельцу ключа: название, владелец ли он, включены ли AI-отчёты и вход через SSO, сколько папок, опросов и участников, и полный список его прав. Половина отказов инструментов — это отсутствующее право, и по этому списку видно заранее, что получится, а что нет. Возможности тарифа — отдельно, в get_workspace_tariff.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond them by disclosing the shape of the response (permission list, feature flags, counts) and by steering tariff questions elsewhere. It does not mention auth requirements or rate limits, so not a 5.
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?
Front-loaded with the core answer ('what this account is and what the owner can do'), then the return contents, then the sibling pointer. The field enumeration is a little dense and the 'half of failures' sentence is slightly editorial, but nothing is wasted.
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?
There is no output schema, so the description must carry the return contract — and it does, listing the exact fields an agent will receive. Combined with the tariff routing note, an agent has everything needed to call and interpret it.
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?
Schema description coverage is 100% for the single workspace_id parameter, and the schema itself points to workspace://list as the source. The description adds nothing about the parameter, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (get account/workspace details) and enumerates exactly what it returns: name, ownership, AI-report and SSO flags, counts of folders/quizzes/members, and the caller's permission list. It also explicitly distinguishes itself from get_workspace_tariff, so an agent can route without opening either schema.
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?
Gives a concrete reason to call it — 'half of tool failures are a missing permission, and this list shows in advance what will and won't work' — and names the alternative for tariff capabilities. It stops short of stating explicit exclusions (e.g. use get_workspace_members for member rosters), but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает свой домен или поддомен аккаунта и состояние его сертификата. Только чтение: привязка домена — это правка DNS на стороне владельца. Нужен, когда публичная ссылка не открывается: чаще всего домен привязан, а сертификат ещё не выпущен.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the safety profile is known. The description adds genuine context beyond that: why it is read-only (binding happens in DNS on the owner's side) and the real-world failure mode it diagnoses (link broken because the certificate is pending).
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?
Three short sentences, each doing distinct work: what is returned, why it is safe/read-only, and when to reach for it. The purpose is front-loaded with no filler.
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?
With no output schema, the description carries the return-value burden and does so adequately by naming the two returned facts (domain/subdomain and certificate state). It does not describe the certificate states that may be returned, which is a minor residual gap for a simple one-parameter read tool.
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?
Single parameter with 100% schema description coverage, including the origin hint '(из workspace://list)', so the schema carries the meaning. The description adds nothing about workspace_id, which is the baseline-3 case when the schema does the work.
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?
States a specific verb (returns) plus the exact resource: the account's domain/subdomain and its certificate state. It also implicitly separates itself from the write counterpart by framing the tool as read-only versus DNS binding done by the owner. An agent can identify this as the diagnostic read without opening any schema.
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?
Gives a concrete trigger — use it when the public link does not open, because the domain is typically bound but the certificate is not yet issued. It also rules out the mutation path (domain binding is a DNS edit on the owner's side), though it never names the sibling manage_workspace_domain explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список рабочих пространств (workspaces), доступных текущему пользователю.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description contributes one real behavioral fact beyond that — the result is limited to workspaces accessible to the current user — but says nothing about ordering, pagination, or the shape/size of the returned list.
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?
A single sentence with no filler; the resource and its scope are front-loaded. Nothing in it is redundant with the structured fields.
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 zero-parameter read-only list tool with full annotation coverage and no output schema, the description covers what is returned and to whom it is scoped, which is the essential information. It could still note whether the list can be empty or what fields each entry contains, but nothing critical for correct invocation is missing.
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 tool takes zero parameters and the schema is empty with additionalProperties=false, so there is nothing for the description to explain. Per the rubric a parameterless tool gets a baseline of 4.
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 states a specific verb ("Возвращает список") and resource ("рабочих пространств (workspaces)"), plus a scope qualifier ("доступных текущему пользователю"). It is clear enough to act on, but it does not name or differentiate itself from adjacent siblings such as get_workspace_details or get_workspace_roles, and the title ("Список аккаунтов") uses different vocabulary (accounts vs. workspaces) that could cause mild confusion.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_workspace_details for a single workspace. The usage is only inferable from the tool name and the scoping phrase, with nothing explicit in the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает права одного участника — те же, по которым отказывает система. Отвечает на вопрос «почему коллега не видит ответы или не может удалить опрос». Показывает роль, доступные папки, отличия прав в отдельных папках (folder_access — в этих папках действуют они, в остальных общий набор), откуда взяты права (из роли или из значений по умолчанию) и поле blocked — причину, по которой участник не работает независимо от прав: invite_not_accepted (не перешёл по приглашению) или email_not_confirmed (не подтвердил почту).
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | ID участника (member_id из get_workspace_members). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. The description adds genuinely non-obvious behavior — that folder_access overrides the general permission set only in those folders, where rights originate (role vs defaults), and that blocked can nullify access entirely regardless of rights.
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?
Purpose is front-loaded and every clause carries real information, but the single long sentence with multiple parenthetical digressions is dense and slightly run-on. It is appropriately sized for a definition with no output schema.
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?
There is no output schema, so the description properly carries the return-value burden: it enumerates role, folders, per-folder overrides, permission source, and the blocked reasons (invite_not_accepted, email_not_confirmed). Combined with fully documented params and safety annotations, nothing essential for correct use is missing.
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?
Schema description coverage is 100%, and both parameters (member_id, workspace_id) already document their source (member_id from get_workspace_members, workspace_id from workspace://list). The description adds no parameter-level meaning, so the baseline of 3 applies.
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?
It states a specific verb+resource (returns the effective access rights of one member) and frames the real-world question it answers, which cleanly separates it from the sibling get_workspace_members (a list) and from the setters set_workspace_member_role/set_workspace_member_folders. An agent can pick it without opening the schema.
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?
The description gives a concrete triggering scenario (diagnosing why a colleague cannot see answers or delete a survey), which is clear context for invocation. It does not explicitly contrast with the nearest alternatives (get_workspace_members, get_workspace_roles), so no exclusion guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает состав аккаунта: участники, их роли, принято ли приглашение, доступные папки и последняя активность. Только чтение — пригласить, сменить роль или исключить участника через MCP нельзя, это делается в интерфейсе. Нужен, когда надо понять, кто работает в аккаунте и почему у коллеги нет доступа.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько участников вернуть, по умолчанию 100, максимум 500. | |
| offset | No | Сколько участников пропустить, по умолчанию 0. | |
| status | No | Кого показать: all — всех (по умолчанию), active — только принявших приглашение, pending — только приглашённых. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by stating that no write path exists through MCP at all and by naming the additional data surfaces returned (invitation acceptance, folders, last activity).
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?
Three sentences, each doing distinct work: what it returns, what it cannot do, when to reach for it. The payload is front-loaded and there is no filler.
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?
There is no output schema, so the description compensates by enumerating the returned fields. Combined with the read-only constraint and the usage trigger, an agent has everything needed to call this correctly at a 4-parameter, 1-required complexity level.
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?
Schema description coverage is 100% and every parameter (workspace_id, limit, offset, status enum) is documented in the schema itself. The description adds no syntax, default, or filtering semantics beyond that, so the baseline 3 applies.
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?
Names a specific verb and resource and enumerates exactly what is returned (members, roles, invitation state, folders, last activity). This separates it cleanly from siblings like get_workspace_member_access, get_workspace_roles, and invite_workspace_member without opening any schema.
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?
Gives an explicit usage trigger ('when you need to understand who works in the account and why a colleague lacks access') and an explicit exclusion (invite/change role/remove cannot be done via MCP, only in the UI). It does not name the sibling tools that do those things, so routing is implied on the positive side rather than pointed at a specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает оформление отчётов уровня аккаунта: общую палитру, библиотеку сохранённых наборов, значения по умолчанию и допустимые значения каждого поля. Опросы с results_appearance_use_shared = true рисуют отчёты общей палитрой; свои цвета опроса при этом сохраняются и вернутся, если флаг выключить.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real semantics: it explains the results_appearance_use_shared flag behavior and that a quiz's own colors are preserved and restored when the flag is disabled. It does not state auth or rate-limit traits, keeping it short of a 5.
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?
Two sentences, front-loaded with the return content and followed by the shared-palette caveat; every sentence earns its place. Slightly dense but well organized with no filler.
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?
With no output schema present, the description compensates by naming what the call returns (palette, presets, defaults, allowed values). For a single-parameter read tool with full annotation coverage, this is nearly complete; only explicit alternative routing is missing.
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?
Schema coverage is 100% and the single workspace_id parameter is documented in-schema (including a workspace://list hint), so the baseline is 3. The description adds no parameter-level detail beyond what the schema provides.
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 gives a specific verb and resource ("Возвращает оформление отчётов уровня аккаунта") and enumerates what is returned: shared palette, saved-preset library, defaults, and allowed values per field. The "account level" scoping separates it from quiz-level theming siblings like apply_quiz_theme and get_theme_details.
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, when-not, or named-alternative guidance. The explanation of the shared-palette/quiz-color relationship is context, not routing advice; an agent must infer that this is the read step preceding update_workspace_report_palette.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает роли аккаунта с их правами и числом участников на каждой роли. Значения прав: allowed — разрешено, partially — только свои объекты, forbidden — запрещено. Только чтение — создание и правка ролей делается в интерфейсе.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the bar is lower. The description adds real value beyond them by decoding the permission tri-state (allowed/partially/forbidden) and noting that each role carries a member count, which shapes how results should be interpreted.
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?
Three short sentences: scope first, then the permission-value glossary, then the read-only constraint. Nothing is padded and the narration is front-loaded on what the tool returns.
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?
With no output schema, the description must hint at the return shape, and it does — roles, their permissions, member counts, plus the encoding of permission values. That covers what an agent needs to consume the result, though it doesn't mention ordering, pagination or whether system/default roles are included.
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?
Only one parameter (workspace_id) with 100% schema description coverage, including its provenance ('из workspace://list'). The description adds nothing about the parameter, which is fine given the schema covers it, so the baseline 3 applies.
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?
States a specific verb and resource ('Возвращает роли аккаунта') plus the payload ('с их правами и числом участников на каждой роли'), which immediately separates it from save_workspace_role and delete_workspace_role in the sibling list. An agent can identify it as the read/list tool for workspace roles without opening the schema.
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?
Explicitly frames the tool as read-only and says role creation/editing happens in the UI, which steers the agent away from trying to mutate. It does not name the alternatives (save_workspace_role) directly, and the UI-only claim is in slight tension with that sibling existing, so it stops short of a clean 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает своё хранилище файлов аккаунта: что подключено (S3 или Яндекс.Диск), работает ли оно, шаблон пути и число файлов в нём. Только чтение — подключить или отключить хранилище через ассистента нельзя, это делается в интерфейсе. Нужен, когда файлы ответов не открываются: чаще всего хранилище отвалилось и запись ушла на диск платформы.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: that the storage configuration is immutable through this tool, and the diagnostic meaning of the returned health state, which the structured fields cannot express.
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?
Three short sentences, front-loaded with what is returned, then the restriction, then the diagnostic use case. Every sentence carries information; no filler or repetition of the name/title.
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?
With no output schema, the description correctly enumerates the fields an agent will get back and explains what the health flag implies. Combined with annotations covering the read-only profile, an agent has enough to call and interpret it; the only gap is not distinguishing it from the sibling storage_usage/verify tools.
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?
Only one parameter, workspace_id, and the schema already documents it at 100% coverage including the reference to workspace://list. The description adds nothing about the parameter, so baseline 3 applies.
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?
States a specific verb+resource (returns the account's file storage) and enumerates the returned facts: provider type (S3 or Yandex.Disk), health, path template, file count. It is clear in isolation, but it does not explicitly distinguish itself from the very close siblings get_workspace_storage_usage and verify_workspace_storage, so an agent still has to guess at the boundary.
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?
Gives a concrete triggering scenario ('needed when answer files don't open: the storage most often dropped and writes went to the platform disk') and a clear exclusion ('you cannot connect or disconnect storage via the assistant, that is done in the UI'). It stops short of naming the alternative tools (storage_usage / verify_storage) that would make the routing unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает занятое файлами место: отдельно диск платформы (он идёт в квоту тарифа) и своё хранилище. Для своего S3 объём считается обходом бакета, для Яндекс.Диска дополнительно показывается остаток места аккаунта.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds real context beyond that: the S3 figure is obtained by traversing the bucket (implying a potentially costly/latency-heavy call) and the Yandex.Disk variant also surfaces the account's remaining space. That is useful behavioral disclosure the annotations cannot convey.
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?
Two sentences, front-loaded with what is returned, then the per-backend computation caveats. Every clause carries information and nothing is padded; it could be marginally tighter but there is no waste.
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?
There is no output schema, so the description must convey the return shape, and it does: platform disk usage, own-storage usage, and (for Yandex.Disk) account remaining space, plus how the S3 number is derived. Adequate for a single-parameter read tool, though it stays silent on formatting/units.
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?
Schema description coverage is 100% and the single workspace_id parameter is already documented in the schema ('ID воркспейса (из workspace://list)'). The description adds nothing about the parameter, so the baseline of 3 applies — the schema does all the work.
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?
States a specific verb and resource ('Возвращает занятое файлами место') and breaks the result into two clearly named components: the platform disk that counts toward the tariff quota and the user's own storage. That is concrete enough for an agent to know what comes back, but it never distinguishes itself from the nearby sibling get_workspace_storage, so it stops short of a 5.
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?
The purpose implies when to call it (checking storage consumption), and the S3/Yandex.Disk clauses hint at backend-specific behavior, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the get_workspace_storage / get_workspace_tariff alternatives an agent would otherwise have to disambiguate from. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает тариф аккаунта целиком: код тарифа, оплачен ли он, сколько дней осталось, все лимиты с остатками (опросы, ответы, участники, темы, место на диске, адреса для писем) и список возможностей — свой домен, своё хранилище, роли, выгрузка ответов, публичные ссылки, AI-отчёт, интеграции. Смотрите сюда, когда действие отклонено «по тарифу»: здесь видно, кончился лимит, истёк срок или возможности нет вовсе. Только чтение — смена тарифа и оплата не через ассистента.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real value by listing the response composition an agent needs for diagnosis and by closing off the mutation path ('changing tariff and payment are not via the assistant'), preventing a futile search for a write sibling.
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?
Three sentences with the purpose front-loaded, then the diagnostic use case, then the read-only boundary. The middle enumeration of limits and features is long but each item is load-bearing because there is no output schema. Minor density cost, no wasted sentences.
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?
With no output schema, the description carries the full burden of describing the return value and does so thoroughly — limits with remainders, payment status, remaining days, and capability list. For a one-parameter, annotation-covered read tool, nothing an agent needs is missing.
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?
There is a single parameter and the schema documents it at 100% coverage (workspace_id sourced from workspace://list). The description adds no syntax, format, or default detail beyond that, so the baseline 3 applies.
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 names a specific verb+resource (returns the account tariff in full) and enumerates exactly what comes back: tariff code, payment status, days remaining, per-resource limits, and capability flags. It is unmistakably a workspace-tariff read, not a catalogue lookup, although it never names sibling get_tariff_list explicitly to draw the contrast.
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?
It gives an explicit triggering context — 'look here when an action was rejected because of the tariff' — and explains what to look for (limit exhausted, term expired, capability absent). It also states the counterpart case (changing/paying for a tariff is not done through the assistant), which implicitly bounds usage, though no sibling alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Показывает собственные шаблоны аккаунта — те опросы, которые сделали шаблонами через make_quiz_template. Это не общий каталог сервиса, его ищет search_quiz_templates. Найденный id передаётся в create_quiz_from_template так же, как каталожный.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько шаблонов вернуть, от 1 до 100. По умолчанию 20. | |
| offset | No | Сколько шаблонов пропустить. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the provenance of the items (created via make_quiz_template) and that the resulting id feeds create_quiz_from_template exactly like a catalog id. It stops short of describing pagination or return format, so not a full 5.
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?
Three short sentences, front-loaded with the identity of the resource, then the sibling boundary, then the id handoff. No filler; every clause carries routing information.
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 an account-scoped template listing whose safety is covered by annotations, parameter contract by a 100%-covered schema, and pagination by limit/offset, nothing an agent needs to call it correctly is missing. The sibling disambiguation and id handoff round it out.
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?
Schema description coverage is 100%: workspace_id, limit (1-100, default 20) and offset are all documented in the schema itself. The description adds no syntax or format detail for these parameters, so the baseline 3 for fully-covered schemas is appropriate.
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?
States a specific verb and resource ('shows the account's own templates') and immediately draws the boundary against the sibling search_quiz_templates, which covers the service-wide catalog. An agent can distinguish it from siblings without opening a schema.
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?
Explicitly says when this tool applies (own templates made via make_quiz_template) versus when it does not (general catalog — use search_quiz_templates), and names the downstream consumer create_quiz_from_template. Both the selection and the follow-up step are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Приглашает человека в аккаунт: на указанный адрес уходит письмо со ссылкой. До перехода по ссылке участник виден в списке, но доступа у него нет. Роль задаёт, что он сможет делать, список папок — какие опросы увидит; пустой список открывает все папки. Число участников ограничено тарифом.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Имя участника в списке аккаунта. | |
| Yes | Почта приглашаемого — на неё уйдёт письмо со ссылкой. | ||
| comment | No | Заметка о человеке, видна только владельцу аккаунта. | |
| role_id | Yes | ID роли (из get_workspace_roles). Роль решает, что человек сможет делать. | |
| folder_ids | No | ID папок, которые увидит участник. Не передавайте или передайте пустой список, чтобы открыть все папки. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-readOnly, non-idempotent, non-destructive, open-world. The description adds real behavioral context beyond that: the invitee is listed but has no access until the link is clicked, role controls permissions, empty folder list grants all folders, and member count is capped by the tariff. Only the failure/duplicate-email behavior is left unstated.
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?
Five compact clauses, front-loaded with the core action, each carrying distinct information (mechanism, pending state, role/folder effects, tariff limit). No filler sentences.
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 mutation tool with no output schema, the description covers the flow and side effects well, including the pending-access state and the tariff cap. It omits error/duplicate-email handling and confirmation of what a successful call returns, but is otherwise sufficient.
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?
Schema description coverage is 100% and documents every parameter, including the empty-folder-list rule. The description's explanation of role and folder effects largely restates what the schema already says, so it adds little beyond the baseline.
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 opening clause states a specific verb and resource ('Приглашает человека в аккаунт') and the mechanism (email with a link). This clearly separates it from siblings like add_quiz_email_recipient and resend_workspace_member_invite.
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?
The description implies the invitation context and states a constraint (tariff-limited member count), but never names an alternative tool or an explicit when-not condition. The agent can infer the use case but gets no routing guidance among the many sibling invite/member tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создает шаблон на основе текущего опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса для сохранения в шаблоны. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a non-read-only, non-idempotent, non-destructive write, so the safety profile is known. Beyond that the description adds almost nothing: it doesn't say whether repeat calls create duplicate templates, whether the source quiz is mutated, or what the caller gets back.
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?
A single front-loaded sentence with no wasted words. It is appropriately sized, though its brevity is partly the source of the gaps noted elsewhere.
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 mutation tool with no output schema and no annotations beyond the safety hints, the description should explain the outcome (e.g., where the template appears, whether it can be reused). Instead it leaves the agent to infer the result of the operation.
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?
Schema description coverage is 100%: quiz_id is fully documented in the schema as the quiz to save as a template. The description adds no further param meaning, so the baseline 3 for schema-complete parameters applies.
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 names a specific verb and resource: 'Создает шаблон на основе текущего опроса' (creates a template based on the current quiz). It is clear what the tool produces, though it does not differentiate itself from the reverse-direction sibling create_quiz_from_template or from search_quiz_templates.
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?
There is no guidance on when to use this tool versus alternatives. The sibling set contains closely related operations (create_quiz_from_template, save_quiz_email_template, get_workspace_templates), yet the description offers no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Доступ к папке со стороны самой папки: показывает, у кого он есть, и выдаёт или снимает его одному человеку. Доступ участника к опросам держится на привязке к папкам. Соседний set_workspace_member_folders смотрит с другой стороны — перезаписывает весь список папок одного участника целиком, поэтому для точечной правки годится этот инструмент. Признак active в списке говорит, принял ли человек приглашение: пока нет, доступ выдан, но им никто не пользуется.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: members — кто имеет доступ, add — выдать доступ, remove — снять. | |
| folder_id | Yes | ID папки (folder://list). | |
| member_id | No | ID участника из get_workspace_members. Нужен для add и remove. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the meaning of the 'active' flag, i.e. that access can be granted while the invite is unaccepted and thus unused. It doesn't discuss reversibility or permission requirements beyond that, so a 4 rather than 5.
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?
Four sentences that are mostly load-bearing, with the core operation stated first and the sibling contrast second. Slightly more prose than strictly needed, but no sentence is filler.
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 4-parameter mutation tool with no output schema, the description covers purpose, alternative routing, and even the shape/meaning of the 'members' result (the active flag). Remaining gaps — error behavior and permission requirements — are minor.
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?
Schema description coverage is 100% and the action enum with members/add/remove semantics is already documented in the schema. The description adds no param-level syntax or constraints beyond that, so the baseline 3 applies.
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?
States a specific resource and three concrete operations ('показывает, у кого он есть, и выдаёт или снимает его одному человеку'), and explicitly contrasts its perspective with the sibling set_workspace_member_folders, so an agent can tell them apart without opening either schema.
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?
Explicitly names the alternative (set_workspace_member_folders), describes how it differs (overwrites the whole folder list for one member), and states the condition that selects this tool — pointwise edits ('для точечной правки годится этот инструмент'). This is textbook when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Заводит, переименовывает и удаляет метки источников партнёрской ссылки. Метка отделяет один канал продвижения от другого: по ней в статистике видно, откуда пришёл человек. Сами метки и статистику по ним показывает get_partner_program. Метки принадлежат партнёру, а не аккаунту.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Название метки, от 3 до 25 символов. Обязательно для rename; при create без него подставится имя по порядку. | |
| action | Yes | Что сделать: create — завести метку, rename — переименовать, delete — удалить. | |
| source_id | No | ID метки из get_partner_program. Нужен для rename и delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says the tool 'удаляет' (deletes) labels, yet the annotation declares destructiveHint=false, which per MCP semantics claims only additive updates. These cannot both be true for the delete action, so this is a direct annotation contradiction. The genuinely useful extras (partner-vs-account ownership, sibling for viewing) do not offset the conflict.
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?
Four short sentences, purpose front-loaded, with each subsequent sentence adding distinct value (label semantics, viewing sibling, ownership). No filler or repetition, though it is slightly longer than strictly necessary for a three-parameter tool.
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 mutation tool with no output schema and no reliable annotations (they contradict the delete behavior), the description covers the conceptual model and routing but omits reversibility of delete, required permissions, and any outcome/error information. Adequate but with clear gaps given the operation's complexity.
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?
Schema description coverage is 100%, so the schema already documents name, action (with enum), and source_id, including the rename/create rules. The description adds conceptual context about what a 'метка' is but no parameter-level syntax or format detail beyond the schema, so the baseline of 3 applies.
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 opening sentence names three specific verbs (create/rename/delete) acting on a concrete resource (partner-link source labels), so the tool's scope is unambiguous. It further distinguishes itself from the read-side sibling by pointing to get_partner_program for viewing, letting an agent tell the two apart without opening either schema.
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?
It explicitly routes the read use case to another tool ("Сами метки и статистику по ним показывает get_partner_program"), which is clear alternative guidance. However, it never states when NOT to use this tool or which action to prefer in a given situation, leaving that to be inferred from the schema enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Правит списки промокодов: переименовывает список, меняет вид кода (текст, QR, штрихкод, DataMatrix) и его размер, удаляет список целиком, убирает отдельный код и привязывает список к другим опросам аккаунта. Завести список и досыпать кодов — это create_promocode_group и add_promocodes. Удаление списка уносит и все его коды, поэтому требует confirm_delete. Промокоды доступны не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Новое название списка. Нужно для update. | |
| action | Yes | Что сделать: update — переименовать или сменить вид кода, delete — удалить список, attach — привязать список к опросам, detach — открепить список от опросов, delete_code — убрать один код. | |
| code_id | No | ID промокода из get_promocode_codes. Обязателен для delete_code. | |
| list_id | No | ID списка промокодов. Не нужен только для detach и delete_code. | |
| quiz_id | Yes | ID опроса, от которого работаем: по нему проверяются права и тариф. | |
| quiz_ids | No | ID опросов, до 200 за раз. Обязателен для attach и detach. | |
| code_width | No | Ширина кода в пикселях, 20–2000. | |
| code_format | No | Вид кода: text, qr, barcode, datamatrix. | |
| code_height | No | Высота кода в пикселях, 20–2000. | |
| confirm_delete | No | Подтверждение, что список удаляется вместе со всеми кодами. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and non-idempotent, but the description adds real behavioral context beyond that: deleting the list also destroys every code in it, deletion is gated behind a confirm_delete flag, and the feature is tariff-dependent. This is meaningful added disclosure, though it does not address permissions or rate/size handling in depth.
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?
The operation list is front-loaded and each following sentence adds a distinct, useful fact (sibling routing, delete consequence, tariff gating). It is dense but not padded; a slightly tighter grouping of the enumeration would make it fully optimal.
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?
Given a 10-parameter multi-action tool with no output schema, the description covers what the tool does, which siblings handle the adjacent operations, the destructive scope of delete, and the confirmation/tariff constraints. It stops short of mapping each action to its required parameters, but the schema's 100% coverage fills that gap.
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?
Schema description coverage is 100%, so the schema already defines every parameter, including the action enum and the code_format values. The description echoes the format/size concepts but adds no syntax or mapping detail beyond what the structured fields provide, so the baseline of 3 is appropriate.
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 names a specific verb+resource (editing promocode lists) and enumerates the concrete sub-operations it performs: rename, change code format/size, delete the whole list, remove a single code, attach to other quizzes. It also explicitly names the sibling tools that handle list creation and code addition, so an agent can distinguish it from create_promocode_group and add_promocodes without opening a schema.
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?
It explicitly routes the agent to alternatives ('Завести список и досыпать кодов — это create_promocode_group и add_promocodes') and states prerequisites: deletion removes all codes and therefore requires confirm_delete, and promocodes are not available on all plans. The when-to-use and the constraint conditions are stated rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сопоставление полей опроса с полями amoCRM. Форма здесь другая, чем у Bitrix24: вместо «сущность → поля» задаётся, что активно, и словари по номерам. Блок deal — сделки в перечисленных воронках, list — контакт (0), компания (1) и каталоги, task — задачи. Задаётся по одному блоку за вызов, блок заменяется целиком, остальные не трогаются. Каждое значение проверяется по живым справочникам портала до записи: воронка существует, стадия принадлежит этой воронке, поле есть в справочнике, ответственный есть в списке. Имена полей и номера воронок смотрите через get_quiz_crm_fields, идентификаторы вопросов — в quiz://{id}/structure. Bitrix24 настраивается отдельным инструментом manage_quiz_crm_mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| bind | No | Сопоставление: ключ — числовой ID поля amoCRM из справочника, значение — ID вопроса опроса. Постоянные значения эта форма не поддерживает. | |
| block | Yes | Что настраиваем: deal — сделки, list — контакт, компания и каталоги, task — задачи. | |
| users | No | Ответственный по каждому номеру воронки. | |
| active | No | Что включено: для deal — номера воронок, для list — 0 (контакт), 1 (компания) и номера каталогов, для task — номера воронок. Пустой список означает «не создавать». | |
| titles | No | Название по каждому номеру из active: либо ID вопроса опроса, либо готовый текст. Если название не собралось, amoCRM подставит «Lead #номер». | |
| quiz_id | Yes | ID опроса. | |
| subtype | No | Уточнение вида значения для составного поля (например, какой это телефон). Ключ — тот же ID поля, что в bind. | |
| statuses | No | Стадия по каждому номеру воронки. Стадия должна принадлежать своей воронке. | |
| use_price | No | Отправлять ли в сумму сделки набранные баллы — по каждому номеру воронки. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply the mutation profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the description doesn't need to restate safety. It does add genuinely useful behavior beyond them: the target block is replaced entirely while others are untouched, and every value is validated against the portal's live directories before writing (pipeline exists, stage belongs to that pipeline, field in directory, assignee in list).
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?
The description is dense but front-loaded: mapping purpose, form differences, block taxonomy, mutation/validation semantics, then lookup references. Every sentence carries information, though it is somewhat crowded and could trim its overlap with the schema.
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 9-parameter mutation tool with nested objects, no output schema, and annotation coverage of the safety profile, the description supplies the missing behavioral context (full-block replacement, live validation, block taxonomy) plus the lookup tools. It is nearly complete, only falling slightly short on return/side-effect specifics.
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?
Schema description coverage is 100%, so the schema already documents all nine parameters, including block meanings, active-list semantics, and the 'Lead #номер' title fallback. The description largely duplicates this content rather than adding new syntax or format detail, so baseline 3 applies.
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 states a specific verb+resource (mapping quiz fields to amoCRM fields) and explicitly differentiates itself from the sibling manage_quiz_crm_mapping (Bitrix24) in the closing sentence. It also enumerates the three blocks (deal/list/task) and their meanings, so an agent can tell it apart from neighboring CRM tools without opening any schema.
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?
It gives explicit routing rules: Bitrix24 is configured by a separate tool, field names and pipeline numbers come from get_quiz_crm_fields, and question IDs come from quiz://{id}/structure. It also states the operational constraint 'one block per call'. Both the alternative tool and the correct data sources are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Счётчики и пиксели опроса: Google Аналитика, Яндекс.Метрика, пиксель VK, пиксель Facebook. Показывает состояние, задаёт номер счётчика, включает, выключает и убирает интеграцию. Номер счётчика не секрет — он виден в коде любой страницы, — поэтому ничего чужого вводить не приходится. Значение пишется и в интеграцию, и в версию опроса, откуда его читает рендер.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show — состояние, save — задать номер, activate — включить, deactivate — выключить, delete — убрать. | |
| counter | No | Номер счётчика или id пикселя, до 20 символов. Пустое значение стирает номер. | |
| quiz_id | Yes | ID опроса. | |
| service | Yes | Какой счётчик: google — Google Аналитика, yandex — Яндекс.Метрика, vk — пиксель VK, fb — пиксель Facebook. | |
| version | No | Только для google: ga4 или ua. | |
| is_webvisor | No | Только для yandex: включить вебвизор — запись действий посетителя. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=false, destructive=false, openWorld=false, and the description adds genuine behavior beyond them: the written value is propagated both into the integration and into the quiz version, from which the renderer reads it. It does not, however, warn that delete removes the integration irreversibly, which would be useful for a tool whose annotation marks destructiveHint=false despite a 'delete' action.
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?
Three sentences, front-loaded with the resource and the operations, then a rationale and a side-effect note. Mostly earns its length, though the 'nothing foreign needs to be entered' clause is filler relative to invocation.
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 6-parameter, 3-required configuration tool with no output schema and adequate annotations, the description covers all five actions and the persistence semantics of saved values. It stops short of stating permission requirements or what the show action returns, but the essentials for correct invocation are present.
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?
Schema description coverage is 100%, and the schema already documents every enum value, the counter max length, and the version/webvisor conditional usage. The description only adds the passing remark that counter values are non-secret and that the value is persisted, which is marginal over the schema baseline.
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 names a specific resource (quiz analytics counters/pixels) and enumerates concrete operations — show state, set counter number, enable, disable, remove — which map onto the action enum. It is clearly distinguishable from most siblings, though it never contrasts itself with the closely related get_quiz_integrations.
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?
There is no explicit when-to-use guidance, no prerequisites, and no routing away from alternatives such as get_quiz_integrations. The sentence about the counter number not being a secret is reassurance for the caller, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Отправка ответов в CRM — amoCRM или Bitrix24. Показывает, включена ли отправка, включает и выключает её и проверяет, живо ли подключение: токен отзывают на стороне CRM, и со стороны опроса это выглядит как молчащая интеграция. Сопоставление полей опроса с полями лида, сделки и контакта здесь не настраивается — это делают в кабинете, там справочники CRM. Подключение портала тоже: там вход в аккаунт CRM. Состояние всех интеграций опроса — в get_quiz_integrations.
| Name | Required | Description | Default |
|---|---|---|---|
| crm | Yes | Какая CRM: amocrm или bitrix24. | |
| action | Yes | Что сделать: show — состояние, activate — включить отправку, deactivate — выключить, check — проверить связь с CRM. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) already convey mutation semantics and external dependency. The description adds genuinely new behavioral context: the token can be revoked CRM-side and this manifests as a silently dead integration, explaining what the 'check' action actually diagnoses. It does not contradict the annotations, though it stops short of describing activation side effects.
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?
Front-loaded with purpose and the operation list, then the boundaries and routing. It is dense and slightly long, but nearly every clause carries distinct information (what it does, what it diagnoses, what it excludes, where to go instead).
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 no-output-schema mutation tool, the description covers operations, the diagnosis scenario, and sibling routing. It is complete enough to call correctly; only the exact shape of the 'show' state return is left implicit, which is a minor gap.
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?
Schema coverage is 100%, so the enum meanings are already documented in the schema. The description nonetheless enriches the 'check' action with the token-revocation rationale, adding meaning beyond the terse schema enum text, while quiz_id and crm need no elaboration.
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?
Names a specific verb+resource (sending quiz answers to amoCRM/Bitrix24) and enumerates the concrete operations: shows whether sending is on, enables/disables it, and checks connection liveness. It also explicitly carves out what it does NOT do (field mapping) versus the sibling manage_quiz_crm_mapping, so an agent can distinguish them without opening schemas.
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?
Explicit when/when-not routing: field mapping is done in the cabinet, portal connection is elsewhere, and overall integration state lives in get_quiz_integrations. The alternative tool is named directly, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сопоставление полей опроса с полями Bitrix24: «пусть телефон из опроса попадает в телефон лида». Задаётся по одной сущности за вызов — lead, contact, company или deal — и заменяет её целиком: чего в переданном наборе нет, того в сопоставлении не останется, остальные сущности вызов не трогает. Прежде чем править, посмотрите справочники и текущее сопоставление через get_quiz_crm_fields: имена полей берутся оттуда, а идентификаторы вопросов — из quiz://{id}/structure. Стадия принадлежит воронке, и несовместимую сохранить нельзя. amoCRM этим инструментом не настраивается: там сопоставление задаётся по воронкам, это делают в кабинете.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Что настраиваем: lead — лид, contact — контакт, company — компания, deal — сделка. | |
| fields | No | Сопоставление: ключ — имя поля Bitrix24 из справочника (TITLE, PHONE, UF_CRM_…), значение — откуда брать. Набор заменяется целиком. | |
| status | No | Статус лида (STATUS_ID) из справочника. Только для lead. | |
| enabled | No | Отправлять ли эту сущность вообще. Без неё сущность не создаётся. Незаданное значение остаётся прежним. | |
| quiz_id | Yes | ID опроса. | |
| title_type | No | Откуда берётся название: Field — из ответа на вопрос, Static — заданный текст. | |
| category_id | No | Номер воронки сделки. 0 — воронка по умолчанию. Только для deal. | |
| title_value | No | Само название: при Field это ID вопроса, при Static — текст. Если название собрать не удалось, Bitrix24 подставит «Lead #номер» или «Deal #номер». | |
| link_to_lead | No | Привязать сделку к созданному лиду. Только для deal. | |
| default_stage | No | Стадия сделки. У воронки по умолчанию не начинается с «C», у воронки N обязана начинаться с «CN:». Только для deal. | |
| add_id_to_title | No | Дописывать номер заявки в название. Только для lead. | |
| company_title_value | No | То же для названия компании. Для lead и company. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false), so the bar is lower, but the description adds material context beyond them: the set is replaced wholesale («чего в переданном наборе нет, того в сопоставлении не останется»), other entities are untouched, and an incompatible stage cannot be saved. The replacement semantics sits uneasily with destructiveHint=false, though it is config-level overwrite rather than data destruction, so this is tension rather than a flat contradiction.
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?
The paragraph is dense but front-loaded: purpose and example first, then the destructive-replace rule, then prerequisites, then the amoCRM carve-out. Nearly every sentence carries a distinct constraint, though the density means key rules are not visually separated.
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 12-parameter mutation tool with nested objects and no output schema, the description covers the essential behavior: replace semantics, single-entity scope, prerequisite lookups, and validation limits. It does not describe the success response, but with no output schema the agent mainly needs to know the write semantics, which are covered.
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?
Schema description coverage is 100%, so the baseline is 3; the description still adds value by telling the agent where field names come from (the справочник via get_quiz_crm_fields) and where question IDs come from (quiz://{id}/structure), plus the «Lead #номер»/«Deal #номер» fallback naming. These operational hints go beyond the per-parameter schema text.
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 states a specific verb+resource with a concrete example («пусть телефон из опроса попадает в телефон лида») and names the boundary explicitly: mapping quiz fields onto Bitrix24 entity fields, one entity per call. It also distinguishes itself from the sibling manage_quiz_amocrm_mapping by stating amoCRM is not configured here, so an agent can route correctly without opening either schema.
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?
It states when to use it (editing CRM mapping for a specific entity), names the read-first alternative get_quiz_crm_fields for reference data and current mapping, and gives the exclusion for amoCRM (per-pipeline mapping done in the cabinet). The one-entity-per-call constraint is stated up front, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Выгрузка ответов в Google Таблицы: что попадает в таблицу и как часто она обновляется. show — состояние: адрес и название таблицы, живой ли доступ, режим обновления, когда выгружали последний раз, какие вопросы исключены. Дальше: включить и выключить выгрузку, убрать интеграцию, задать состав вопросов, переключить метку времени и персональные данные, выбрать режим обновления (сразу, по расписанию в заданный час, вручную), дослать накопившееся и выгрузить все ответы заново. Подключение аккаунта Google и выбор таблицы делают в кабинете: там вход в аккаунт и окно Google Диска. Журнал синхронизаций — в get_quiz_integrations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show, activate, deactivate, delete, save_widgets — состав вопросов, save_switchers — метка времени и персональные данные, set_sync_mode — режим обновления, sync_now — дослать накопившееся, export_all — выгрузить все ответы. | |
| quiz_id | Yes | ID опроса. | |
| sync_mode | No | Когда обновлять таблицу: realtime — сразу после ответа, scheduled — раз в сутки в заданное время, manual — только по команде. Обязателен для action=set_sync_mode; при scheduled нужны ещё schedule_hour и schedule_minute. | |
| export_mode | No | Куда выгружать все ответы: new_file — в новый файл, new_sheet — на новый лист, replace — заменить текущий лист. Обязателен для action=export_all. | |
| schedule_hour | No | Час обновления, 0–23. Обязателен для scheduled. | |
| schedule_minute | No | Минута обновления, 0–59. Обязательна для scheduled. | |
| enable_timestamp | No | Добавлять столбец со временем ответа. | |
| hidden_widget_ids | No | ID вопросов, которые НЕ попадают в таблицу. Список задаётся целиком: чего в нём нет, то в таблицу вернётся. Взять из quiz://{id}/structure. | |
| enable_personal_data | No | Выгружать персональные данные респондента. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, non-idempotent and non-read-only, so the safety profile is partly carried structurally. The description adds real context beyond that: what 'show' returns (table address/name, live access status, update mode, last export, excluded questions) and the three sync modes. It does not call out irreversibility of delete or overwrite semantics of export_all/replace, which a destructive multi-action tool would ideally state.
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?
Purpose and the most important action ('show') are front-loaded before the enumeration of remaining actions. It is a single dense paragraph rather than a scannable list, which is a minor structural weakness, but every sentence carries information and none is padding.
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 9-parameter, 9-action tool with no output schema, the description covers purpose, action inventory, state-reading via 'show', prerequisites, and where logs are found, so an agent can invoke it correctly. What is missing is return/error behavior for the mutating actions and any warning about destructive outcomes, which keeps it below a 5.
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?
Schema description coverage is 100% and the schema itself already documents each enum value, cross-field dependencies (sync_mode required for set_sync_mode, schedule_hour/minute for scheduled, export_mode for export_all) and the whole-list semantics of hidden_widget_ids. The prose largely restates the action list, adding little syntax or format detail beyond the schema, so the baseline 3 applies.
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 opening states a specific verb+resource (exporting answers to Google Sheets) and then enumerates every action the tool performs, mapping transparently onto the action enum (show, activate, deactivate, delete, save_widgets, save_switchers, set_sync_mode, sync_now, export_all). An agent can tell this apart from the CSV/XLSX/SPSS export siblings because it is the live Sheets-integration manager, not a one-off file export.
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?
It gives clear operational context: 'show' reveals current state, account connection and table selection happen in the cabinet rather than through this tool, and synchronization logs live in get_quiz_integrations. This explicit routing to another tool/cabinet is strong. It stops short of an explicit when-not-to-use rule versus the static export tools, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Настройки отправки ответов в мессенджер — Telegram или MAX. Показывает, куда именно уходят заявки: список чатов, групп и людей, тему сообщения, какие вопросы из него исключены, есть ли кнопки. Позволяет включить и выключить отправку, убрать интеграцию, убрать одного получателя, задать состав сообщения и отправить пробное. Токены здесь не вводят: бот платформенный, человек лишь добавляет его в чат по ссылке из ответа. Журнал доставки — в get_integration_logs.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show — настройки и получатели, activate — включить (и получить ссылку добавления бота), deactivate — выключить, delete — убрать интеграцию, toggle_buttons — кнопки под сообщением, save_widgets — состав сообщения и тема, remove_recipient — убрать одного получателя, test — пробное сообщение. | |
| quiz_id | Yes | ID опроса. | |
| subject | No | Тема сообщения, до 70 символов. Применяется при save_widgets. | |
| messenger | Yes | Какой мессенджер: telegram или max. | |
| recipient_id | No | ID получателя из show. Нужен для remove_recipient. | |
| buttons_enabled | No | Присылать ли кнопки под сообщением. Нужно для toggle_buttons. | |
| hidden_widget_ids | No | ID вопросов, которые НЕ надо включать в сообщение. Список задаётся целиком: чего в нём нет, то в сообщение вернётся. Взять из quiz://{id}/structure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false. The description adds genuinely non-obvious context beyond them: the bot is platform-level, the user only adds it to a chat via a link, no tokens are entered, and delivery history lives in a separate tool. It does not spell out irreversibility of 'delete'/'remove_recipient' beyond what the annotations imply.
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?
A dense but front-loaded paragraph that opens with the resource and then lists operations. It repeats the field list (chats/groups/people, subject, excluded questions, buttons) after already framing it as what 'show' returns, which is mild redundancy, but overall it is efficient and scannable.
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 an 8-action tool with no output schema, the description is largely self-sufficient: it sketches what 'show' returns, explains the platform-bot/token model, and points to get_integration_logs. It does not describe error cases or confirm what a 'test' or 'activate' call returns, which would complete it fully.
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?
Schema coverage is 100%, so the schema already documents every parameter, including the inverse-list semantics of hidden_widget_ids and the save_widgets/toggle_buttons conditions. The description reinforces these meanings (subject, excluded questions, buttons, recipients) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
Names a concrete resource (sending quiz answers to Telegram/MAX) and enumerates the operations it performs (show, activate, deactivate, delete, toggle buttons, save widgets, remove recipient, test). It routes the log-reading case to get_integration_logs, but does not explicitly contrast itself with the email-notification siblings (e.g. toggle_quiz_email), leaving the messenger-vs-email boundary implicit.
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?
Gives clear operational context: it shows where requests go and lets you enable/disable, remove integration/recipient, edit composition and send a test. It also states a usage constraint ("Токены здесь не вводят") and redirects log needs to get_integration_logs. No explicit when-not guidance versus the email tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ведёт список паролей доступа к закрытому опросу: показывает заведённые, добавляет новые, заменяет и удаляет. Пароли хранятся хешами, поэтому прочитать заведённый пароль нельзя ни здесь, ни в конструкторе — только заменить новым. В списке видны номер и дата: по номеру в ответах автор узнаёт, кто из приглашённых отвечал. Сама проверка пароля на входе включается настройкой use_password в update_quiz_settings.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: list — показать список, add — добавить, update — заменить пароль, delete — удалить. | |
| quiz_id | Yes | ID опроса. | |
| password | No | Пароль. Обязателен для update — это новое значение взамен прежнего. Для add его можно передать вместо списка passwords, если пароль один. | |
| passwords | No | Список паролей для add, до 50 штук за раз. Нужно больше — вызовите несколько раз: пароль хешируется, и большая пачка не успела бы обработаться. | |
| password_id | No | ID пароля из list. Нужен для update и delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses a genuinely non-obvious behavior: passwords are stored as hashes so the value can never be read back anywhere, only overwritten. It also explains that the list exposes number and date to identify respondents. It omits auth/permission requirements and rate limits, keeping it short of a 5.
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?
Front-loads the purpose, then adds hashing, list content, and the enabling setting in a compact block of sentences. Every sentence carries information, though the number/date explanation is slightly tangential.
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 multi-action tool with no output schema, this covers the essentials: what each action does, that reads of the secret are impossible, what the list returns, and how enforcement is toggled. Missing only permissions/no-output detail, which is minor here.
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?
Schema description coverage is 100% and the field descriptions already cover password vs passwords, password_id, and update semantics. The prose largely restates what the schema documents (replace, list IDs) and adds no new format or constraint detail, so the baseline of 3 applies.
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 opens with a precise verb+resource and enumerates the four supported operations (list/add/update/delete), which map directly to the action enum. It clearly identifies this as the access-password manager for a closed quiz and even names the sibling (update_quiz_settings) that controls the entry check.
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?
It gives clear context: passwords cannot be read (only replaced), and the entry check is enabled via use_password in update_quiz_settings, which routes the agent to the right sibling. It stops short of an explicit when-not-to-use statement, but the operational framing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Приём оплаты в опросе через ЮKassa. show — текущие настройки, список счетов продавца аккаунта (без секретных токенов) и виды расчёта суммы. save — выбрать счёт, задать вид расчёта (фиксированная сумма или сумма по набранным баллам), саму сумму и вопрос, из которого берут контакт для чека. Счета продавца здесь не заводятся и не правятся: для них нужны идентификатор магазина и секретный токен ЮKassa, а платёжные ключи через ассистента не передают — это делают в кабинете. Отдельного переключателя «включить оплату» нет: оплата работает, когда у аккаунта есть счёт продавца и тариф разрешает виджет оплаты, а показ самого вопроса с оплатой задаётся его виджетом через update_quiz_widgets.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show — настройки и счета, save — сохранить настройки. | |
| quiz_id | Yes | ID опроса. | |
| fixed_amount | No | Сумма к оплате. Обязательна при fixed: без неё оплата ушла бы на ноль. | |
| payment_type | No | Как считается сумма: fixed — фиксированная, scoring — по набранным баллам. Обязателен для action=save. | |
| contact_widget_id | No | ID вопроса, из которого берут контакт для чека (почта или телефон). Взять из quiz://{id}/structure. null — не брать. | |
| yookassa_account_id | No | ID счёта продавца из show. Обязателен для action=save. Чужой счёт увёл бы платежи другому продавцу, поэтому проверяется принадлежность аккаунту. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses substantive behavior: secret tokens are never returned or transmitted, accounts are not created or edited here, and there is no 'enable payment' toggle — payment works only when a seller account exists and the tariff permits the widget. These are exactly the constraints an agent needs before invoking.
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?
It is dense but front-loaded: purpose and action semantics come first, followed by prerequisites and exclusions. Every sentence carries information, though the prerequisite paragraph is long enough that a reader must parse several clauses before reaching the boundary conditions.
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?
With no output schema, the description compensates by describing what show returns (settings, seller accounts without secret tokens, calculation types) and by spelling out prerequisites and the absence of a toggle. Nothing an agent needs to call it correctly appears to be missing.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by describing the save workflow — choosing an account, a calculation type (fixed vs. points), the amount, and the question supplying the receipt contact — tying the parameters into a coherent operation rather than restating them.
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 states a specific verb+resource: accepting payment in a quiz via YooKassa, and then splits it into the two actions (show/save) with their concrete effects. It is clearly distinguishable from generic quiz tools and from update_quiz_widgets, which it explicitly names as a different concern.
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?
It explains when each action applies (show for current settings/accounts, save to configure account, calculation type, amount and receipt-contact question) and explicitly routes related work elsewhere — seller accounts require store ID and secret token and are managed in the cabinet, not through the assistant, and widget display is set via update_quiz_widgets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
QR-код опроса: наклейка на столе, слайд на конференции, листовка у стойки. Показывает текущий код и настройки, собирает новый и убирает логотип из центра. Код ведёт на опубликованный опрос, поэтому неопубликованный опрос получает отказ. Загрузить логотип отсюда нельзя — это делают в кабинете, — но уже загруженный код учитывает. Повторный вызов с теми же настройками отдаёт готовый файл и не пересобирает его: каждая сборка списывает место с тарифа.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Сторона картинки в точках, 100–1000. По умолчанию — как в прошлый раз, иначе 320. | |
| color | No | Цвет кода, шестизначный HEX вида #000000. | |
| force | No | Пересобрать код, даже если настройки не менялись. | |
| action | Yes | Что сделать: show — текущий код и настройки, generate — собрать код, delete_logo — убрать логотип из центра. | |
| format | No | Формат файла: png, svg или eps. По умолчанию — как в прошлый раз, иначе png. | |
| margin | No | Поля вокруг кода, 0–10. По умолчанию 1. | |
| quiz_id | Yes | ID опроса. | |
| background | No | Цвет фона, шестизначный HEX вида #ffffff. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: the code targets a published quiz, repeated calls with unchanged settings return the cached file instead of rebuilding, and every build consumes tariff quota. These quota and precondition behaviors are not in the annotations. It stops short of describing the returned artifact's form, and the caching claim sits in mild tension with idempotentHint=false, though the 'force' parameter explains why that flag is false.
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?
The action semantics and the routing constraint (published-only, no logo upload here) are front-loaded before the caveats. The opening list of use-cases ('sticker', 'slide', 'flyer') is illustrative but adds little operational value, making it slightly longer than strictly necessary.
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 an 8-parameter mutation tool with no output schema, the description covers the important gaps: preconditions, quota cost, caching behavior, and the fact that logo upload is out of scope. Only the exact return payload (file/link) is left implicit, which is minor.
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?
Schema coverage is 100% and each parameter already documents type, enum, range, and defaults (e.g. size 100–1000, format png default). The description adds no per-parameter syntax beyond the generic word 'settings', so the schema does the work; baseline 3 applies.
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?
States specific verbs and resource: shows the current code/settings, builds a new one (generate), and removes the center logo (delete_logo), all scoped to a quiz's QR code. An agent can distinguish this from siblings like upload_workspace_logo or update_quiz_settings without opening the schema.
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?
Gives clear when/when-not: only for published quizzes (unpublished is rejected), and explicitly says logo upload must be done elsewhere ('это делают в кабинете'). It names a condition rather than a specific sibling tool name, which is slightly less actionable but still routes the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ведёт наборы уникальных ссылок на опрос — отдельных адресов вида https://<домен опроса>/s/<код> для отдела, филиала, класса или партнёра. У каждой ссылки лимит ответов (свой или набора), у набора — срок, недельное расписание, правило пароля и свои тексты отказа. Ответ помнит ссылку, по ней фильтруются ответы и отчёт (unique_link_group_id / unique_link_ids в get_quiz_answers и generate_filtered_report). Основной адрес опроса работает как раньше. Чтение — по праву view_results, изменения — по праву settings. Ошибка проверки приходит машинным кодом поля, например «max_uses: max_uses_range».
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ID ссылок для bulk_links. Без ids действие применяется ко всему, что отбирают search и show, на всех страницах. Для delete нужны ids, search или show, отличный от all. | |
| name | No | Название набора для create_group, до 120 символов. | |
| page | No | Страница для list_links, с 1. | |
| show | No | Отбор для list_links и для bulk_links без ids: all — все, no_answers — без ответов, answered — с ответами, limit_reached — набран лимит, unavailable — не пускают. | |
| count | No | Сколько ссылок выпустить: для create_group и add_links, 1..1000. Не учитывается, если переданы labels. | |
| action | Yes | Что сделать: list_groups — наборы, get_group — один набор, create_group — создать набор со ссылками, update_group — изменить набор, delete_group — удалить набор со ссылками, list_links — ссылки набора по странице, add_links — добавить ссылки, update_link — изменить ссылку, bulk_links — включить, выключить или удалить несколько ссылок, export_links — файл со ссылками набора (CSV или Excel) по ссылке на скачивание. | |
| format | No | Формат файла для export_links: xlsx (по умолчанию) или csv. Ссылка на скачивание действует час. | |
| labels | No | Названия ссылок для create_group и add_links: по ссылке на каждое непустое имя, в этом порядке, до 1000, каждое до 64 символов. | |
| search | No | Подстрока кода или своего названия ссылки — для list_links и для bulk_links без ids. | |
| changes | No | Изменяемые поля. Для update_group: name, active, max_uses, starts_at, expires_at (моменты ISO), period_timezone, schedule_enabled, schedule_days (ISO 1..7), schedule_time_from, schedule_time_to (HH:mm), schedule_timezone, password_mode (survey — пароли опроса, own — пароль набора, none — без пароля), password (только запись), message_used, message_invalid (HTML, до 1000 символов текста). Для update_link: label, active, own_max_uses вместе с max_uses (свой лимит только сужает лимит набора), own_password, password_add, password_edit {id, value}, password_delete (id пароля), params — скрытые переменные ссылки [{name, value}], до 20. | |
| dry_run | No | Для update_group: только посчитать, сколько ссылок перестанут пускать при новом max_uses (becomes_used), ничего не сохраняя. | |
| link_id | No | ID ссылки. Нужен для update_link. | |
| quiz_id | Yes | ID опроса. | |
| group_id | No | ID набора. Нужен для get_group, update_group, delete_group, list_links, add_links, bulk_links и export_links. | |
| max_uses | No | Лимит ответов на ссылку для create_group: 1 — одноразовые (по умолчанию), N, или null — без лимита. | |
| per_page | No | Ссылок на странице для list_links, до 500, по умолчанию 50. | |
| bulk_action | No | Для bulk_links: enable — включить, disable — выключить, delete — удалить. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true/non-idempotent/open-world, so the bar is lower, yet the description adds real value: the required permissions for reads vs writes, the fact that responses and reports are filtered by unique_link_group_id/unique_link_ids, and the machine error-code format (e.g. 'max_uses: max_uses_range'). These are behavioral details not covered by 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?
It is a long description, but front-loads the entity definition and then layers on limits, filtering, rights and error format, each sentence carrying distinct information. Appropriate sizing for a 10-action, 17-parameter tool, with only mild redundancy.
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 complex destructive multi-action tool with nested objects and no output schema, it covers the entity model, permission requirements, filtering side effects, and error format. The only gap is that return values are not described, but the detailed action enum compensates substantially.
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?
Schema description coverage is 100%, so the schema already documents all 17 parameters in detail (including the nested changes object and enum values). The description adds little parameter-level meaning beyond the domain framing, so the baseline 3 is correct.
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 names a specific resource (sets of unique survey links of form /s/<code>) and the managing verb, and it explicitly distinguishes its scope from the main survey address ('Основной адрес опроса работает как раньше'), separating it from set_quiz_link. An agent can grasp the domain without opening the schema.
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?
It lists all available operations and states the read-vs-write rights model (view_results for reads, settings for changes), which implies when it is usable. However it gives no explicit when-to-use/when-not or routing to sibling tools like set_quiz_link or manage_quiz_passwords. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Интеграция опроса с Zapier. Со стороны опроса это один переключатель: включена отправка ответов или нет. Сами связки собираются на стороне Zapier, ключей здесь вводить не нужно. Удаление снимает и подписки — связка в Zapier перестанет получать ответы, и собирать её придётся заново там же.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show — состояние и число связок, activate — включить, deactivate — выключить, delete — убрать интеграцию вместе с подписками. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that 'Удаление снимает и подписки — связка в Zapier перестанет получать ответы, и собирать её придётся заново', i.e. the delete action removes subscriptions and is irreversible without rebuilding. This directly conflicts with the annotation destructiveHint=false, which tells the agent the tool performs only additive updates. That is a material conflict, so per the rule it scores 1.
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?
Four sentences, front-loaded with what the tool is, then how it works, then the delete consequence — every sentence carries useful information and there is no padding. Slightly redundant between the 'switch' framing and the wiring note, so not quite a 5.
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 2-parameter toggle with no output schema, the description covers the operational model (no keys needed, one switch) and the most consequential behavior (delete removes subscriptions and requires rebuilding). It would be more complete if it named the sibling integrations tools, but the essentials for a correct call are present.
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?
Schema description coverage is 100%: quiz_id and the action enum (show/activate/deactivate/delete) are already fully documented in the schema, including that delete removes subscriptions. The description adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.
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 states a specific verb+resource ('Интеграция опроса с Zapier' / toggling answer forwarding) and frames the tool as a single switch, so an agent knows exactly what it controls. It does not, however, name or distinguish itself from adjacent siblings such as get_quiz_integrations or manage_quiz_webhook, which keeps it at 4 rather than 5.
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?
It gives real usage context: 'Само стороны Zapier это один переключатель', that the wiring is assembled on the Zapier side, and that no keys are entered here — useful framing for when this tool (not a key-entry or webhook tool) is the right choice. It provides no explicit when-not or alternative-tool comparison, so it lands at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Наводит порядок в темах оформления: делает копию темы, чтобы не переписывать её с нуля, удаляет ненужную и возвращает удалённую. Опросы, которые пользовались удалённой темой, переводятся на тему по умолчанию — иначе опубликованный опрос сломался бы. Список тем — в theme://list.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: copy — копия темы, delete — удалить, restore — вернуть удалённую. | |
| theme_id | Yes | ID темы из theme://list. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses a critical side effect the structured fields cannot convey: deleting a theme reassigns any quizzes using it to the default theme, because otherwise a published quiz would break. That is exactly the kind of cascade consequence an agent needs before invoking a destructive action.
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?
Two tightly packed sentences: the operations come first, then the deletion consequence, then the resource pointer for the list. No filler, and the most important warning is not buried.
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 destructive, non-idempotent mutation tool with no output schema, the description covers the essential side effect of deletion and where to find theme IDs. It is largely complete, though it says nothing about restore preconditions (e.g. whether an already-deleted theme is required) or what copy returns.
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?
Schema description coverage is 100%: the enum values and both ID parameters are already documented in the schema, including the theme://list and workspace://list provenance. The description adds no format, constraint, or edge-case detail beyond that, so the baseline 3 applies.
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 names a specific resource (themes) and enumerates the three concrete operations (copy, delete, restore), so an agent can immediately tell this apart from single-purpose siblings like create_theme or update_theme. It does not explicitly name those siblings as the alternative, which is the only thing separating it from a 5.
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?
Each action carries an implicit reason to use it: copy exists 'so you don't have to rewrite the theme from scratch', delete is for unwanted themes, restore brings back deleted ones. This gives clear context for choosing an action, but there is no explicit when-not guidance or pointer to a sibling tool for the cases this tool does not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Активные входы в аккаунт: где человек ещё залогинен и закрытие лишнего входа. Показывает устройство, браузер, город и когда заходили последний раз. Внимание: close_all закрывает ВСЕ входы в браузерах, включая тот, из которого человек сейчас работает в кабинете, — в кабинете эта кнопка оставляет текущий вход, а здесь текущего входа нет, потому что ассистент работает по ключу. Поэтому close_all требует подтверждения.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: list — список входов, close — закрыть один, close_all — закрыть все. | |
| session_id | No | Идентификатор входа из list. Нужен для close. | |
| confirm_close_all | No | Подтверждение для close_all: человека выкинет и из кабинета, в котором он сейчас работает. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description goes well beyond that: it explains exactly what is destroyed (all browser logins), and critically that there is no 'current session' to preserve when called via the assistant because the assistant operates with a key, which is why close_all demands confirmation. That is precisely the kind of non-obvious behavioral context an agent cannot derive from 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?
The opening sentence front-loads the resource and its two operations, and the snapshot of returned fields comes next. The close_all warning is verbose and the cabinet-vs-assistant comparison is somewhat convoluted, but no sentence is pure filler given the destructive stakes.
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 three-parameter mutation tool with no output schema, the description covers the destructive action thoroughly and the 100%-covered schema handles inputs. It does not describe the shape of the list result (fields beyond device/browser/city), but with no output schema that omission is minor.
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?
Schema description coverage is 100%, so both session_id and confirm_close_all are already documented in the schema, including that confirm_close_all implies the user is kicked out of the cabinet they are working in. The description reinforces the semantics of close_all but adds little that is not already in the schema text, so the baseline 3 is appropriate.
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 names a specific resource (active account sessions/logins) and the operations (listing entries and closing redundant ones), plus what data is exposed (device, browser, city, last login). It is clearly distinguishable from siblings like get_user_me or update_user_profile, which touch the account but not its sessions. It stops short of a crisp one-line verb+resource statement because the purpose is delivered as prose rather than a header.
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?
It gives explicit guidance for the risky path: close_all closes every browser session including the one the person is currently using in the cabinet, and therefore requires confirmation. That is a clear when-to-be-careful rule. However, it never frames the ordinary choice between list, close, and close_all, so the routing among the three actions is left to the schema enum rather than stated in prose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Адрес, по которому открываются опросы аккаунта: служебный адрес сервиса, поддомен аккаунта или свой домен. Инструмент показывает текущее состояние вместе с состоянием сертификата, задаёт поддомен и переключает используемый адрес. Подключение своего домена сюда не входит: там нужна правка DNS на стороне владельца и выпуск сертификата с недельным лимитом на повторы — это делают в кабинете. Адрес отдельного опроса внутри домена меняет set_quiz_link.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Что сделать: show — текущее состояние, set_subdomain — задать поддомен, set_type — переключить используемый адрес. | |
| subdomain | No | Имя поддомена. Обязателен для set_subdomain; чтобы убрать поддомен, передайте пустую строку. | |
| domain_type | No | Какой адрес использовать: default — служебный, subdomain — основной поддомен, other_subdomain — дополнительный, domain — свой домен. Обязателен для action=set_type. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. | |
| subdomain_kind | No | Какой поддомен задаём: default — основной, other_subdomain — дополнительный. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-idempotent, non-destructive write with open-world effects, so the bar is lowered. The description adds genuine context beyond them: certificate status is surfaced by the show action, and custom-domain work needs DNS changes plus a certificate with a weekly retry limit. It stops short of describing side effects of switching the address type (e.g., whether the previous address stops resolving) or required permissions.
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?
Purpose is front-loaded, followed by scope and the sibling pointer; each sentence carries content. Slightly dense, with the exclusion clause packing in DNS and certificate-limit details that could be trimmed, but nothing is wasted.
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?
There is no output schema, yet the description tells the agent that show returns current state plus certificate state, which is the key return-value expectation. For a mixed read/write address tool with fully documented parameters, only the consequences of set_type and permission requirements are left unstated.
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?
Schema description coverage is 100% and every parameter (including the three enums) is fully documented in the schema itself. The description adds no additional parameter meaning, so the baseline of 3 applies.
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?
States a specific resource (the account's quiz-facing address) and enumerates the three operations: show current state with certificate status, set a subdomain, and switch the address type. It also names which address kinds exist (service, subdomain, custom) and explicitly routes per-quiz link changes to set_quiz_link, so the agent can distinguish it from siblings without opening a schema.
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?
Explicitly states what is out of scope — connecting a custom domain, which requires owner-side DNS edits and certificate issuance with a weekly retry cap done in the dashboard — and names the sibling that handles the adjacent task (set_quiz_link). When-to-use, when-not-to-use, and the alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Файлы аккаунта: чем занято место и чистка. overview — сколько занято, сколько разрешает тариф и разбивка по опросам. list — сами файлы с фильтрами по опросу, виду медиа, хранилищу и владельцу, с поиском и сортировкой. delete — удаление выбранных файлов или всех файлов перечисленных опросов. Удаление необратимо: файл респондента приложен к его ответу, и после удаления в ответе останется ссылка в никуда, поэтому нужно подтверждение. Загрузить файл через ассистента нельзя, скачать архивом — тоже. Скрытые из-за нехватки места файлы — в get_workspace_hidden_files.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Страница, с 1. | |
| owner | No | Чьи файлы: owner — загруженные автором в опрос, respondent — присланные респондентами, both — и те, и другие (для delete). | |
| action | Yes | Что сделать: overview — сводка по месту, list — список файлов, delete — удалить. | |
| search | No | Поиск по имени файла. | |
| quiz_id | No | Показать файлы только этого опроса. Для list. | |
| sort_by | No | Сортировка: quiz_id, size, created_at или storage. | |
| storage | No | Где лежит файл: default — наше хранилище, s3 или yandex_disk — своё хранилище аккаунта. | |
| file_ids | No | ID конкретных файлов из list. Без них нужен delete_all. | |
| per_page | No | Файлов на странице, 1–200. По умолчанию 30. | |
| quiz_ids | No | Опросы, в которых удаляем файлы. Обязательно для delete. | |
| delete_all | No | Удалить все файлы перечисленных опросов, а не выбранные. Идёт очередью, поэтому число удалённых в ответе не приходит. | |
| file_uuids | No | UUID файлов респондентов из list. У них нет числового id — только uuid, поэтому удалять их надо этим полем. | |
| media_type | No | Вид медиа: image, video или audio. | |
| workspace_id | Yes | ID аккаунта из workspace://list. | |
| confirm_delete | No | Обязательное подтверждение удаления: восстановить файлы нечем. | |
| sort_direction | No | Направление сортировки: asc или desc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds crucial context: deletion is irreversible, respondent files are attached to answers and leave broken links, and confirmation is required. It also notes hidden files live in another tool, adding behavioral nuance beyond 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?
The description is dense but every sentence serves a purpose: purpose, action breakdown, irreversibility, confirmation, limitations, and alternative. It is front-loaded with purpose but could be slightly more structured with bullet points for actions.
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?
No output schema exists, yet the description covers return information for overview and list, and explains the destructive delete behavior. It addresses limitations (no upload/download) and points to the hidden-files tool, making it complete for an agent given the rich schema and destructive annotation.
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?
Schema coverage is 100%, so the schema already documents all 16 parameters. The description summarizes list filters (quiz, media type, storage, owner, search, sorting) but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.
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?
States a specific verb+resource: account files for space overview and cleanup. It enumerates the three actions (overview, list, delete) and their scope, and explicitly routes hidden-file queries to get_workspace_hidden_files, distinguishing it from siblings. An agent can tell what it does without opening the schema.
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?
Explicitly describes when to use each action and names the alternative tool for hidden files. It also states two when-not conditions: cannot upload or download archives via assistant. This gives clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Наводит порядок в папках аккаунта: переименовывает папку, удаляет её или переставляет папки в нужном порядке. Удаление папки уносит и все опросы внутри неё вместе с ответами респондентов, поэтому непустая папка удаляется только с параметром confirm_delete_quizzes. Папку по умолчанию удалить нельзя. Список папок — в folder://list.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Новое название папки, до 255 символов. Нужно для rename. | |
| action | Yes | Что сделать: rename — переименовать, delete — удалить, reorder — переставить папки. | |
| folder_id | No | ID папки. Нужен для rename и delete. | |
| folder_ids | No | Полный список ID папок в желаемом порядке. Нужен для reorder. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. | |
| confirm_delete_quizzes | No | Подтверждение, что опросы внутри папки удаляются вместе с ней. Без него непустая папка не удаляется. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds substantive context beyond them: deletion cascades to all quizzes and respondent answers, non-empty deletion requires the confirm_delete_quizzes flag, and the default folder is protected. It does not mention required permissions/roles for management, so not a full 5.
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?
Front-loaded with the action set and immediately followed by the highest-risk consequence (cascading delete). Dense and largely waste-free, though the confirm/default-folder clauses could be slightly tighter.
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?
No output schema exists, and the description covers the dangerous behavior and a resource pointer so an agent can call it safely. Gaps remain on reorder semantics and required permissions, but the critical destructive path is fully explained.
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?
Schema description coverage is 100%, so the schema already documents all six parameters including the action enum and the confirm_delete_quizzes guard. The description reinforces the delete precondition but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb+resource cluster (renames/deletes/reorders account folders) and the three discrete actions are enumerated. An agent can separate it from siblings like create_folder (creates), get_folder_list (reads), and manage_folder_access (permissions) without opening the schema.
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?
Gives clear conditional guidance: a non-empty folder is deleted only with confirm_delete_quizzes, and the default folder cannot be deleted. It also routes to the folder://list resource. It stops short of naming explicit alternatives for the rename/reorder cases, so no exclusions/alternatives tier, but the when-conditions are concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Своя почтовая служба аккаунта: письма респондентам уходят через SMTP владельца, а не сервиса. Инструмент показывает настройки (пароль не отдаётся — только признак, что он задан), включает и выключает уже заведённое подключение, отправляет пробное письмо на адрес владельца ключа и отдаёт журнал отправок с текстом отказа почтового сервера. Само подключение — хост, логин, пароль — заводит человек в кабинете: чужие учётные данные здесь не принимаются.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько записей журнала вернуть, от 1 до 200. По умолчанию 50. | |
| action | Yes | Что сделать: show — настройки, logs — журнал отправок, enable — включить, disable — выключить, test — пробное письмо. | |
| offset | No | Сколько записей журнала пропустить. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds real context beyond them: the password is never returned (only a flag that it is set), the test email targets the key owner's address, and the log includes the mail server's refusal text. This meaningfully enriches the agent's expectations.
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?
A single dense paragraph that front-loads the core purpose before the capability list and the setup constraint. Slightly packed, but each clause conveys distinct behavior; no filler.
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 multi-action tool with no output schema, the description adequately covers what each action does and the nature of the returned data (settings, log with refusal text, test result). Minor gaps remain around log structure and limits, but the essentials for correct invocation are present.
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?
Schema description coverage is 100%, so all four parameters (action enum, limit, offset, workspace_id) are already fully documented in the schema. The description reinforces the action meanings but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 states a specific resource (the workspace's own SMTP mail service) and enumerates concrete capabilities: showing settings, toggling an existing connection, sending a test email, and returning the delivery log. It is clear what the tool does, though it never distinguishes itself from nearby siblings like get_mailing_state or manage_workspace_domain.
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?
Usage is implied through the action-level breakdown (show/logs/enable/disable/test), and there is one useful exclusion — credentials must be created by a human in the dashboard and third-party credentials are rejected. However, no explicit when-to-use-vs-alternative routing against sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Перемещает опрос в другую папку пользователя.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса для переноса. | |
| folder_id | Yes | ID целевой папки. Взять из folder://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the description is not the primary carrier here. Beyond that, it adds no behavioral context: it does not say whether the quiz leaves the old folder, whether this needs edit rights on both folders, or what the non-idempotency hint means in practice.
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?
A single front-loaded sentence with no filler; the verb and destination are stated immediately.
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 simple two-parameter move with full schema coverage and a complete annotation set, the description is nearly sufficient. It would be stronger if it mentioned authorization requirements or what happens when the quiz is already in the target folder, given the idempotent=false hint.
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?
Schema description coverage is 100% and both parameters are documented inline, including the useful pointer to folder://list for folder_id. The description adds nothing beyond that, so the baseline of 3 applies.
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?
Names a concrete verb ('Перемещает') and resource ('опрос') plus the target container ('в другую папку пользователя'), so the operation is unmistakable. It does not differentiate itself from folder-management siblings such as manage_workspace_folder or set_workspace_member_folders, so it stops short of a 5.
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?
The description gives no indication of when this tool should be chosen over alternatives, nor any prerequisites, side effects, or exclusions. The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Публикует опрос: текущая локальная версия становится публичной.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса для публикации. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the write/safety profile is covered. The description adds one genuinely useful behavioral fact — that the current local version becomes the public one — but says nothing about reversibility (can it be unpublished?), permissions required, or side effects on an already-published version, despite idempotentHint=false implying repeat calls matter.
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 tight sentence, verb-first, with the outcome clause front-loaded; no filler or redundancy. It is efficient, though the extreme brevity leaves little room for the supporting details an agent would benefit from.
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 mutation with a clear annotation profile and no output schema, the description is minimally adequate. However, for a publish operation the agent still lacks the key operational facts — reversibility, permissions, and behavior when the quiz is already published — so it is sufficient but not complete.
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?
Schema description coverage is 100% with a single documented parameter ('ID опроса для публикации'), so the schema already carries the parameter meaning. The description adds nothing beyond what the schema states — baseline 3 is appropriate.
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?
States a specific verb and resource ('Публикует опрос') and adds the resulting state change ('текущая локальная версия становится публичной'). It is clear what the tool does and it is distinguishable from siblings like archive_quiz or restore_quiz_version, though it never names any alternative explicitly.
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?
There is no guidance on when to use this tool versus alternatives (archive_quiz, restore_quiz_version, set_quiz_link) and no prerequisites such as whether the quiz must already be saved or have a valid structure before publishing. The agent must infer the context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Исключает участника из аккаунта: доступ пропадает сразу, вместе с привязками к папкам. Созданные им опросы остаются в аккаунте. Вернуть человека можно только новым приглашением, и папки придётся назначить заново.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | ID участника (member_id из get_workspace_members). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, yet the description adds real substance beyond them: access revoked immediately, folder bindings removed, created surveys preserved, and re-entry only via a new invite with folders reassigned. This is exactly the kind of destruction-scope disclosure the annotations cannot convey.
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?
Three tight sentences with the action and its consequence front-loaded. Each sentence carries distinct information (effect, survivals, reversibility), though the phrasing could be marginally more compact.
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 destructive mutation with no output schema, the key decision inputs (immediate loss of access and folder links, preserved surveys, non-trivial restoration path) are all disclosed. No output schema means return values need not be described.
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?
Schema description coverage is 100%, so both parameters (member_id, workspace_id) are already documented with their sources. The description adds no parameter-level detail, making the baseline 3 appropriate.
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 states a specific verb and resource ('Исключает участника из аккаунта') and the immediate effect. It is clearly distinguishable from read-oriented siblings like get_workspace_members, but it does not name alternatives such as set_workspace_member_role for role changes.
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?
Usage is implied rather than stated: the warnings about irreversibility ('Вернуть человека можно только новым приглашением') tell the agent this is a high-consequence action, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. role change vs. removal).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Переименовывает существующий опрос.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Новое название опроса (максимум 80 символов). | |
| quiz_id | Yes | ID опроса, который нужно переименовать. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether renaming is reversible, whether the name must be unique, whether an error is returned for a missing quiz, or what side effects (version bump, updated_at) occur.
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?
A single short, front-loaded sentence with no filler or repetition. It is efficient, though arguably terse to the point of under-specification rather than genuinely well-structured.
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?
This is a simple two-parameter mutation with no output schema, and annotations cover the safety profile, so a minimal description is nearly sufficient. Still, it omits error conditions and side effects, leaving the agent to assume behavior for a non-idempotent write.
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?
Schema description coverage is 100% (both name and quiz_id are documented in the schema, including the 80-character limit), so the schema does the heavy lifting. The description adds no syntax, format, or constraint information beyond it, making the baseline 3 appropriate.
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 states a specific verb and resource ('Переименовывает существующий опрос' = renames an existing quiz), which is enough to distinguish it from sibling mutators like update_quiz_settings or move_quiz. However, it makes no explicit reference to any sibling, so an agent gets no help choosing among the many quiz-mutation tools.
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?
The description gives no when-to-use context, no prerequisites (e.g. must the quiz be unpublished? does the caller need ownership rights?), and no mention of alternatives such as update_quiz_settings. Nothing beyond the bare operation is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Дослать в мессенджер то, что не ушло. Нужен, когда причина сбоя устранена: бота вернули в группу, токен перевыпустили — накопившиеся заявки иначе так и останутся в журнале. Можно повторить одну запись по log_id или все неудачные за период. Отправка идёт очередью, поэтому в ответе — сколько поставлено в очередь; дошло или нет, покажет get_integration_logs.
| Name | Required | Description | Default |
|---|---|---|---|
| log_id | No | ID одной записи из get_integration_logs. Без него повторяются все неудачные. | |
| date_to | No | Конец периода для повтора пачкой, в формате ГГГГ-ММ-ДД. | |
| quiz_id | Yes | ID опроса. | |
| date_from | No | Начало периода для повтора пачкой, в формате ГГГГ-ММ-ДД. | |
| integration | Yes | Куда досылать: telegram или max. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, open-world, non-idempotent, non-destructive, and the description adds genuinely non-obvious behavior: the send is queued, so the response only reports how many were enqueued, not whether delivery succeeded. That asynchronous return semantics is exactly the kind of trait annotations cannot express. It stops just short of describing partial-failure handling or rate limits.
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?
Four tightly packed sentences: purpose, precondition, modes, and return semantics — front-loaded with no filler. Every sentence introduces a distinct, actionable fact.
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?
With no output schema, the description correctly explains the return shape (enqueued count, not delivery outcome) and how to confirm success. Annotations carry the safety profile, so nothing critical is missing; it only lacks detail on partial failures or retry limits.
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?
Schema description coverage is 100%, so all five parameters are already documented, including the log_id-vs-batch behavior and the telegram/max enum. The description restates the log_id/batch distinction without adding syntax or format detail beyond the schema. Baseline 3 is appropriate.
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?
Names a specific verb+resource ('resend to messenger what failed to send') and immediately frames it against the sibling read tool get_integration_logs and the retry pattern. An agent can distinguish it from resend_quiz_webhook_log and get_integration_logs without opening a schema.
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?
States the exact precondition for use ('when the cause of failure is fixed: bot returned to a group, token reissued') and gives the two operating modes: one record by log_id or all failures for a period. It also routes the agent to get_integration_logs to verify delivery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Повторяет отправку по записи журнала — после починки приёмника, не дожидаясь нового ответа респондента.
| Name | Required | Description | Default |
|---|---|---|---|
| log_id | No | ID записи журнала (из get_quiz_webhook_logs). | |
| date_to | No | Конец периода для массовой додосылки, в формате ГГГГ-ММ-ДД. | |
| quiz_id | Yes | ID опроса. | |
| date_from | No | Начало периода для массовой додосылки, в формате ГГГГ-ММ-ДД. | |
| webhook_id | Yes | ID вебхука (из get_quiz_webhooks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the agent knows this is a non-idempotent outbound write. The description adds the fix-receiver scenario but omits significant behavior: the schema exposes date_from/date_to for bulk resending, yet the description frames it as operating on a single log entry, leaving the bulk mode undisclosed.
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?
A single dense sentence with the action front-loaded and the motivating condition trailing. No waste, though the brevity contributes to the missing bulk-mode detail.
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?
With 5 parameters, no output schema, and a mass-resend mode implied by date_from/date_to, the description should at least flag the bulk variant. Annotations cover safety, but the single-entry framing is incomplete for the tool's actual surface.
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?
Schema description coverage is 100%, so the schema already documents all five parameters, including the bulk date range. The description adds no parameter-level meaning beyond the schema and even under-describes the mass-resend path; baseline 3 is appropriate when the schema carries the load.
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?
States a specific verb+resource — repeating the send for a journal entry ('Повторяет отправку по записи журнала') — which distinguishes it from generic resend tools. It does not name the close sibling resend_integration_logs or otherwise delimit scope against it, so it stops short of a 5.
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?
Gives clear when-to-use context: after the receiving endpoint is fixed, without waiting for a new respondent submission. It does not name alternatives or exclusions (e.g. when to prefer resend_integration_logs), so no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Отправляет приглашение повторно — когда письмо потерялось или ссылка устарела. Участнику, который уже принял приглашение, письмо не отправляется.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | ID участника (member_id из get_workspace_members). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds useful behavioral context: an already-accepted member receives no email, which is not derivable from the annotations alone, though permissions and rate limits remain unstated.
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?
Two concise sentences with no filler. The primary use condition is front-loaded, and the exclusion case follows immediately.
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 low-complexity mutation with full parameter documentation and relevant annotations, the description covers the key trigger and no-op case. It could mention permissions or response behavior, but those are secondary given the annotations and schema.
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?
Schema description coverage is 100%, and both member_id and workspace_id are documented in the schema with provenance hints. The description adds no further parameter meaning, so the baseline score of 3 is appropriate.
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?
States a specific action (resends an invitation) and resource (workspace member), plus the trigger conditions. The word 'повторно' and the lost-email/expired-link context clearly distinguish it from an initial invite operation.
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?
Explicitly says when to use it (lost email or expired link) and when not to use it (the member already accepted the invitation). It does not name the alternative sibling invite_workspace_member, so tool routing is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает удалённый опрос из корзины — со всеми вопросами, логикой и ответами. Опрос снова занимает место в тарифном лимите, поэтому при исчерпанном лимите вернуть не получится. Архив — другое: снять опрос с архива умеет archive_quiz.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_ids | Yes | ID опросов, до 100 за раз. | |
| workspace_id | Yes | ID workspace. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive, non-read-only mutation, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: the restore reinstates all questions, logic, and answers, and it consumes tariff-limit space, which can block the operation. It could go further on permissions or idempotency, but the added constraint is meaningful.
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?
Three compact sentences, front-loaded with the restore action, followed by the tariff-limit failure condition and the archive_quiz alternative. Every sentence carries routing or constraint value with no waste.
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 two-parameter mutation tool with full schema coverage and no output schema, the description supplies purpose, failure mode, and sibling routing. Nothing essential for correct invocation is missing.
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?
Schema description coverage is 100%, with both parameters documented in the schema, including the 100-quiz cap and the workspace://list source for workspace_id. The description adds no parameter-level syntax or meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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?
States a specific verb and resource: restoring a deleted quiz from trash, and specifies that questions, logic, and answers come back with it. It also explicitly distinguishes itself from archive_quiz, so an agent can route between restoring from trash and removing from archive without opening either schema.
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?
Gives a clear when-to-use condition (a deleted quiz sits in trash) and a when-not condition (if the tariff limit is exhausted, restore will fail). It names the alternative archive_quiz for the different task of unarchiving, which is exactly the sibling-ambiguation needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает содержимое прежнего снимка опроса в черновик — это откат неудачной правки. Респондентов откат сразу не касается: живая версия остаётся прежней, пока опрос не опубликуют заново через publish_quiz. Так автор сначала смотрит, что вернулось, и только потом выпускает это наружу. Список снимков — в get_quiz_versions.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| version_id | Yes | ID снимка из get_quiz_versions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly=false, destructive=false and idempotent=false, so the safety frame is partly covered, but the description adds real behavioral context: the rollback only touches the draft, respondents and the live version are unaffected until a republish via publish_quiz. That side-effect/when-it-takes-effect detail is exactly what annotations don't convey.
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?
The rollback purpose is front-loaded, then the non-impact on respondents and the publish workflow follow. Every sentence carries information, though the publish explanation runs slightly long for a two-parameter tool.
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 mutation tool with 100% schema coverage and no output schema, the description covers the essential unknowns: what is overwritten (the draft), what is not (live/respondents), and how it pairs with publish_quiz and get_quiz_versions. Minor details like overwrite of existing draft content are implied rather than stated.
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?
Schema description coverage is 100% and both params are documented ('ID опроса', 'ID снимка из get_quiz_versions'). The description references get_quiz_versions for the snapshot list, which only echoes the schema's own hint, so the baseline of 3 applies.
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?
States a specific verb and resource: returning the content of a previous quiz snapshot into the draft, framed as rolling back a failed edit. The snapshot/version concept clearly separates it from the sibling restore_quiz and get_quiz_versions. It stops short of explicitly contrasting with restore_quiz, but the purpose is unmistakable.
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?
Gives a clear use case ('откат неудачной правки') and routes the agent to get_quiz_versions for the snapshot list and publish_quiz for the follow-up publish step. It explains the intended workflow (review first, publish second). No explicit when-not-to-use guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет вопрос в библиотеку аккаунта, а с указанным favorite_question_id — перезаписывает уже сохранённый. В библиотеке лежит снимок: правка исходного опроса библиотеку не меняет, и наоборот. До 100 вопросов на воркспейс.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Снимок вопроса — объект виджета из quiz://{id}/structure. До 64 КБ. | |
| name | Yes | Название в библиотеке, до 255 символов. | |
| choice_type | No | Для вопросов выбора: text или image. | |
| widget_type | Yes | Тип вопроса, как в структуре опроса (choice, input, matrix и т.д.). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). | |
| source_quiz_id | No | Опрос, из которого взят вопрос. Необязательно, только для справки. | |
| choice_multiple | No | Для вопросов выбора: разрешено несколько ответов. | |
| source_widget_id | No | UUID вопроса в этом опросе. Необязательно, только для справки. | |
| favorite_question_id | No | ID сохранённого вопроса для перезаписи. Не передавайте, чтобы добавить новый. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (write, non-idempotent, non-open-world) it discloses three non-obvious traits: the library stores a snapshot decoupled from the source quiz (edits don't propagate either way), the overwrite behavior of the favorite_question_id path, and a 100-question-per-workspace quota. It stops short of permissions/auth requirements or error behavior.
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?
Three short sentences, front-loaded with the primary action and its overwrite variant, then the snapshot caveat and the quota. No filler, though the snapshot sentence could be trimmed slightly.
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 9-parameter mutation with a nested data object and no output schema, the description covers the critical decision (add vs overwrite), the snapshot semantics, and the quota. Missing only peripheral items such as permission requirements and failure modes.
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?
Schema description coverage is 100%, so the schema already documents all nine parameters including favorite_question_id, data, and the source_* reference fields. The description reinforces the favorite_question_id overwrite semantics but adds no syntax or format detail beyond the schema, so a baseline 3 is appropriate.
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 names a concrete verb+resource (saves a question into the account library) and clarifies the two modes of operation: new save vs. overwrite when favorite_question_id is supplied. Siblings like get_favorite_questions and delete_favorite_question are easy to tell apart by name, so the description is clear without needing to name them explicitly.
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?
It gives the decisive usage fork: omit favorite_question_id to add, pass it to overwrite an existing saved entry. There are no explicit exclusions or named alternatives, but the context for choosing each mode is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Задаёт тему и текст писем опроса. Два независимых письма: автору о новом ответе и копия респонденту. Не переданные поля не трогаются. Адрес респондента здесь не задаётся: он берётся из ответа на вопрос или из скрытой переменной, на которую указывает client_source.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| owner_letter | No | Текст письма автору, до 5000 символов. | |
| client_letter | No | Текст письма респонденту, до 5000 символов. | |
| client_source | No | Откуда брать адрес респондента: имя скрытой переменной опроса или идентификатор вопроса с почтой. | |
| owner_subject | No | Тема письма автору, до 500 символов. | |
| client_subject | No | Тема письма респонденту, до 500 символов. | |
| owner_raw_html | No | Полностью свой HTML письма автору — уходит как есть, без обёртки WebAsk. Работает только с подключённым своим SMTP. | |
| client_raw_html | No | Полностью свой HTML письма респонденту. Работает только с подключённым своим SMTP. | |
| owner_raw_enabled | No | Включить полностью свой HTML для письма автору. Без своего SMTP письмо всё равно уйдёт визуальным шаблоном — инструмент об этом предупредит. | |
| client_raw_enabled | No | Включить полностью свой HTML для письма респонденту. | |
| owner_send_promo_code | No | Класть промокод в письмо автору. | |
| client_send_promo_code | No | Класть промокод в письмо респонденту. | |
| owner_formatted_letter | No | Визуальный шаблон письма автору: HTML из редактора. Именно он уходит, если не включён стандартный шаблон или режим своего HTML. | |
| owner_reply_to_address | No | Адрес для ответа в письме автору: UUID вопроса, из ответа на который берётся адрес. | |
| owner_use_default_tmpl | No | Использовать стандартный шаблон для письма автору. | |
| client_formatted_letter | No | Визуальный шаблон письма респонденту: HTML из редактора. | |
| client_reply_to_address | No | Адрес для ответа в письме респонденту: обычный адрес почты. | |
| client_use_default_tmpl | No | Использовать стандартный шаблон для письма респонденту. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds valuable behavior beyond annotations: 'Не переданные поля не трогаются' discloses partial-update semantics, and the note about client_source explains that respondent address comes from elsewhere. It does not cover permission or SMTP prerequisites, but those appear in the schema.
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?
The description is three front-loaded sentences with no wasted text. It moves from the core purpose to the two-email scope, then to update and address caveats. It is appropriately sized for an 18-parameter tool, though it could be slightly more structured with explicit labels for the caveats.
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?
Given 18 parameters, one required field, annotations covering safety and idempotency, and no output schema, the description supplies the essential behavioral context: what is saved, the two independent email templates, partial-update behavior, and where the respondent address comes from. It does not explain the raw HTML/SMTP interaction in detail, but that is covered by the schema descriptions.
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?
Schema description coverage is 100%, so the detailed parameter meanings are already documented in the schema. The description adds a small amount of semantic context for client_source and the partial-update behavior, but it does not significantly extend parameter semantics beyond what the schema provides. The baseline of 3 is appropriate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Задаёт тему и текст писем опроса' (sets subject and text of quiz emails). It immediately distinguishes the two independent email streams, author and respondent, and clarifies that respondent address is not configured here. This is enough for an agent to distinguish it from siblings like get_quiz_email_settings or set_quiz_email_questions.
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?
The description gives clear context for usage: two independent letters, non-passed fields are left untouched, and respondent address is not set via this tool but sourced from an answer or hidden variable via client_source. It does not explicitly name an alternative sibling tool, but the when-not guidance for respondent address and the partial-update semantics are strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет набор фильтров списка ответов или отчёта. Тот же набор читают экран, публичная ссылка, PDF и Word — то есть он меняет и то, что видят другие люди, а не только вашу выдачу. Сначала прочитайте текущий набор в quiz://{id}/report_filters. На тарифах без опции сохранённых фильтров набор не сохраняется вовсе.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Какой набор сохранять: answers — список ответов, report — отчёт. | |
| filters | Yes | Объект фильтров той же формы, что в quiz://{id}/report_filters. Срез по завершённости задаётся ключом filled; корзина фильтром не хранится. У типа report есть ключ statuses — по каким ответам считается отчёт: массив из completed (завершившие), unfinished (ушедшие до конца) и screenout (дисквалифицированные). Ключ не передан — прежний срез остаётся; пустой массив и неизвестные значения приводятся к [completed]; unfinished и screenout доступны не на всех тарифах и на закрытом тарифе отбрасываются. Этот же срез действует в PDF, Word и по публичной ссылке. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly=false, idempotent=false, destructive=false. The description adds substantial context beyond them: the saved set is shared across the screen, public link, PDF and Word, so it changes what other people see, and on non-eligible tariffs nothing is saved at all. That is exactly the kind of blast-radius disclosure a mutation tool needs.
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?
Four short sentences, front-loaded with the effect, then reach, then prerequisite, then tariff caveat. No filler and nothing repeated from annotations or the title.
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 3-param mutation tool with no output schema, the description covers shared-state impact, a read-before-write prerequisite and a tariff gate — everything an agent needs to call it safely. It only omits what a successful call returns (e.g., the saved set or an id), which is a minor gap.
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?
Schema description coverage is 100% and the filters object is documented in depth in the schema itself (filled key, statuses semantics, coercion rules), so the schema carries the parameter burden. The description adds no parameter-level detail of its own; baseline 3 applies.
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?
States a specific verb+resource ('Сохраняет набор фильтров списка ответов или отчёта') and immediately distinguishes itself from the read-side sibling get_quiz_report_filters by naming what is being persisted. An agent can tell it apart from the get_*/export_* filter tools without inspecting schemas.
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?
Gives a clear prerequisite ('сначала прочитайте текущий набор в quiz://{id}/report_filters') and a when-not condition (tariffs without the saved-filters option don't persist anything). It stops short of naming the get_quiz_report_filters tool explicitly, leaving the agent to map the resource URI to the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт расписание записи, а с указанным scheduler_id — правит существующее; не переданные поля не трогаются. Время задаётся двумя способами: weekly — повторяющиеся часы по дням недели, самый частый случай; slots — список конкретных дат и интервалов для разовых встреч. Все даты и часы указываются в часовом поясе расписания, а не респондента: респонденту слоты пересчитываются при показе.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Название расписания, до 250 символов. | |
| color | No | Цвет расписания в интерфейсе. | |
| weekly | No | Рабочие часы по дням недели: [{"day": 1, "intervals": [{"start": "10:00", "end": "18:00"}]}]. День 1 — понедельник. | |
| timezone | No | Часовой пояс расписания, например Europe/Moscow. | |
| is_active | No | Принимает ли расписание записи. | |
| overrides | No | Исключения на диапазон дат: [{"dateFrom": "2026-09-10", "dateTo": "2026-09-12", "intervals": [{"start": "12:00", "end": "15:00"}], "comment": "короткие дни"}]. | |
| daily_limit | No | Максимум записей в день. null — без ограничения. | |
| description | No | Описание, которое видит респондент. | |
| max_advance | No | Насколько вперёд открыта запись: {"type": "rolling", "days": 30}, {"type": "range", "from": "2026-09-01", "to": "2026-12-31"} или {"type": "infinite"}. | |
| admin_emails | No | Адреса администраторов через запятую. | |
| buffer_after | No | Свободные минуты после встречи. | |
| manual_slots | No | Конкретные слоты для режима slots: [{"date": "2026-09-10", "start": "10:00", "end": "10:30", "seats": 1}]. | |
| notify_admin | No | Слать администратору письма о новых записях. | |
| scheduler_id | No | ID расписания для правки. Не передавайте, чтобы создать новое. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). | |
| buffer_before | No | Свободные минуты перед встречей. | |
| location_type | No | Где проходит встреча: online, phone, address или custom. | |
| schedule_mode | No | weekly — повторяющиеся часы по дням недели, slots — список конкретных дат. | |
| slot_duration | No | Длительность встречи в минутах, от 5 до 1440. | |
| location_value | No | Сама ссылка, телефон или адрес. | |
| seats_per_slot | No | Сколько человек помещается в один слот. | |
| slot_increment | No | Шаг сетки слотов в минутах. null — сетка идёт по длительности встречи. | |
| confirmation_mode | No | auto — запись подтверждается сразу, manual — подтверждаете вручную. | |
| notify_respondent | No | Слать респонденту письма о записи. | |
| min_notice_minutes | No | За сколько минут до начала ещё можно записаться. | |
| allow_respondent_cancel | No | Разрешить респонденту отменить запись по ссылке из письма. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic readOnly=false / destructive=false profile. The description adds real behavioral value beyond them: partial-update semantics ('fields not passed are untouched') and the timezone contract (input dates/hours are in the schedule's timezone, not the respondent's, and slots are recalculated on display). It stops short of permissions, limits or error behavior.
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?
Four sentences, no filler, and correctly front-loaded: create-vs-edit contract first, then the two time modes, then the timezone caveat. Every sentence carries a distinct decision-relevant fact.
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 26-parameter, nested-object tool with no output schema, the description covers the highest-value decision points (mode selection, update semantics, timezone) while the schema docs the remaining fields. It is adequate, though it could tie timezone/mode more explicitly to the parameter names it governs.
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?
Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter meaning the schema does not: what weekly vs slots actually represent and how timezone interacts with how slots are shown to respondents. That semantic layer exceeds the per-parameter descriptions.
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 names a specific verb pair (creates / edits) tied to a specific resource (booking schedule) and explicitly states the scheduler_id switch that selects update over create. This lets an agent distinguish save_scheduler from siblings like delete_scheduler, duplicate_scheduler and get_schedulers without opening any schema.
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?
It clearly frames the two operating contexts: omit scheduler_id to create, pass it to edit with untouched fields preserved. It also gives in-tool guidance on when to pick weekly (recurring, 'the most common case') vs slots (one-off dates). It does not, however, name any sibling alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт роль или меняет права существующей. Правка действует сразу на всех участников этой роли. Значения прав: allowed — разрешено, partially — только свои объекты, forbidden — запрещено. Без role_id создаётся новая роль, с role_id — правится указанная. Настройка ролей доступна не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название роли. | |
| role_id | No | ID роли для правки (из get_workspace_roles). Не передавайте, чтобы создать новую. | |
| permissions | Yes | Полный набор прав роли. Имена прав берите из get_workspace_roles. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). | |
| folder_permissions | No | Отличия прав роли в отдельных папках: список записей {folder_id, permissions}. Не передавайте, чтобы оставить отличия как есть; пустой массив снимает все, и роль везде работает по базовым правам. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds genuinely useful behavioral context beyond that: an edit takes effect immediately for every member of the role, and the feature is tariff-gated. It does not explain reversibility or the non-idempotent nature flagged by 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?
Four short sentences, front-loaded with the core create-or-edit behavior, then permissions legend, then role_id rule, then tariff caveat. Efficient, though the permission-value enumeration duplicates what is already in the enum description.
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 5-parameter mutation tool with 100% schema coverage and no output schema, the description covers create-vs-edit semantics, the cross-member blast radius of edits, the permission value legend, and a tariff constraint. An agent has what it needs to invoke it correctly.
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?
Schema description coverage is 100%, so the schema already documents name, role_id, permissions, folder_permissions and the allowed/partially/forbidden enum. The description largely restates the permission value meanings (allowed/partially/forbidden) and the role_id create-vs-edit rule that the schema also states, adding little beyond the baseline.
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?
States a specific tool behavior: creates a role OR edits the permissions of an existing one, with an explicit rule for which happens (no role_id → create, with role_id → edit). The note that an edit propagates immediately to all members of that role also distinguishes it from member-level assignment siblings like set_workspace_member_role.
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?
Gives clear conditional guidance for role_id (create vs. edit) and a prerequisite constraint ('Настройка ролей доступна не на всех тарифах'). It stops short of naming alternative tools (get_workspace_roles as source, delete_workspace_role as the removal path) or stating exclusions, so it is strong context without full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ищет опрос в каталоге готовых: NPS, отзыв о заведении, заявка на услугу и прочие уже собраны. Каталог есть на русском и английском. Без query возвращает каталог целиком. Найденный template_id передаётся в create_quiz_from_template.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | Язык каталога: ru или en. | |
| limit | No | Сколько шаблонов вернуть, от 1 до 100. По умолчанию 30. | |
| query | No | Что искать — по названию, описанию и меткам. Без него вернётся весь каталог. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral context the annotations don't: that the catalog exists in Russian and English, and that omitting query returns the entire catalog. No return format or size behavior beyond the schema's limit is disclosed, keeping it from a 5.
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?
Four compact sentences, purpose front-loaded, followed by language coverage, query behavior, and the workflow hand-off. No wasted clauses, though the sentences are somewhat telegraphic and could integrate the query note more tightly.
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 read-only search tool with no output schema and fully documented parameters, the description supplies purpose, language options, no-query behavior, and next-step usage. The main gap is the absence of any differentiation from get_workspace_templates, which an agent selecting a template-listing tool would want.
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?
Schema coverage is 100% and each parameter already has a description, so the baseline is 3. The description's notes on language availability and the no-query behavior largely restate what the schema already says ('Без него вернётся весь каталог'). It adds little beyond the structured fields.
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?
States a specific verb ('ищет') and resource ('опрос в каталоге готовых') with concrete examples (NPS, отзыв о заведении, заявка на услугу). This clearly tells an agent what the tool returns. It does not, however, distinguish itself from the sibling get_workspace_templates, which could cause confusion about catalog-vs-workspace sources.
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?
It implies how to use the tool (query-less calls return the whole catalog) and names the downstream tool create_quiz_from_template, which is helpful workflow guidance. But it never states when to prefer this over alternatives like get_workspace_templates or generate_ai_quiz. Usage is implied rather than explicitly bounded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ставит короткую пометку у отдельного ответа респондента — «перезвонить», «дубль», «жалоба». До 100 символов. Пустое значение снимает пометку. Это не заметка к опросу целиком (та в update_quiz_note) и не тег (те в tag_answer).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Текст пометки, до 100 символов. Пусто — снять пометку. | |
| quiz_id | Yes | ID опроса. | |
| answer_id | Yes | ID ответа из quiz://{id}/answers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly=false, destructive=false), so the bar is lower. The description adds real behavioral context: the 100-character cap and that an empty value removes the note, which is mutation semantics not conveyed by the hints.
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?
Front-loaded with the core action and examples, then constraints, then disambiguation, with no filler. Slightly dense due to the dash-separated example list and trailing negation clause, but every sentence earns its place.
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 simple mutation tool with full schema coverage, annotations, and no output schema, the description covers purpose, examples, size limit, removal semantics, and sibling disambiguation. Nothing an agent needs to invoke it correctly is missing.
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?
Schema coverage is 100%, so all three parameters (note, quiz_id, answer_id) are already documented, including the max length and empty-removes behavior. The description mostly restates these, so baseline 3 applies.
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?
States a specific verb ('ставит') and resource ('пометку у отдельного ответа респондента'), plus concrete example values. It explicitly distinguishes itself from two siblings (update_quiz_note, tag_answer), so an agent can tell it apart without opening schemas.
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?
Names the two near-neighbor tools and states the conditions that route to them ('не заметка к опросу целиком', 'не тег'), giving explicit when-not and alternatives. Little is left to inference for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Задаёт порядок вопросов внутри карточки ответа: respondent — в том порядке, в каком человек реально проходил опрос, survey — в порядке вопросов самого опроса. Тот же порядок получают публичная ссылка на ответы и выгрузка в Word, то есть настройка меняет и то, что видят другие.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| answers_order_mode | Yes | respondent — как проходил человек, survey — как вопросы идут в опросе. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark this as a non-destructive write, so the description carries the behavioral burden - and it does add real value by disclosing a cross-surface side effect: the same order governs the public answers link and the Word export, i.e. 'настройка меняет и то, что видят другие.' It still omits permissions required and whether the change applies retroactively to existing answers.
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?
Two sentences, zero padding, front-loaded with the action and immediately followed by the mode definitions and the side effect. Every clause earns its place.
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 tiny two-parameter setting tool with full schema coverage, no output schema, and annotations covering the safety profile, the description is nearly sufficient: purpose, both modes, and downstream effects are covered. Only permission requirements and retroactivity of the change are left unstated.
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?
Schema description coverage is 100% and the enum's own description already defines 'respondent' and 'survey'. The description paraphrases the same meaning rather than adding syntax, defaults, or edge-case behavior, so the baseline 3 applies.
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?
States a specific verb and resource: 'Задаёт порядок вопросов внутри карточки ответа' (sets the order of questions in the answer card), with both modes spelled out. The resource is unique among siblings (set_answer_note, toggle_answer_visibility, set_quiz_email_questions), but no sibling is named or contrasted explicitly, so it stops short of a 5.
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?
The two mode semantics ('respondent' = actual respondent path, 'survey' = survey question order) imply which to pick, but the description never states when to choose one over the other for a given task, and names no alternatives or exclusions. Usage is inferred rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Задаёт, какие вопросы не попадают в письма. По умолчанию письмо содержит все вопросы и ответы на них, здесь перечисляются исключения — например, чтобы не слать в почту персональные данные или служебные поля. Списки независимы: письмо автору и копия респонденту могут скрывать разное. Передаётся полный список исключений, а не добавка: пустой список возвращает в письмо все вопросы.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| owner_excluded_questions | No | UUID вопросов, которые не попадут в письмо автору. Не передавайте поле, чтобы оставить текущий список. | |
| client_excluded_questions | No | UUID вопросов, которые не попадут в копию респонденту. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial value beyond the annotations: list replacement semantics ('full list, not a delta'), the reset behavior of an empty list, and the independence of the owner and respondent lists. One tension: the annotations declare idempotentHint=false, while full-replacement semantics normally imply idempotency; this is a minor inconsistency rather than a direct contradiction. No permission or scope-of-effect (future vs. sent emails) detail is given.
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?
Four tight sentences, purpose front-loaded, followed by default behavior, rationale, list independence, and the replacement rule. No filler; each sentence carries distinct, actionable information.
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 3-parameter mutation tool with no output schema and existing annotations, the description covers defaults, replacement semantics, and reset behavior well. It stops short of stating required permissions or whether changes affect already-sent emails, which would complete the picture.
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?
Schema description coverage is already 100%, so the baseline is 3, but the description adds meaning the schema lacks: that the supplied array is a complete replacement rather than an append, and that the two exclusion lists are independent. This is exactly the semantic an agent needs to avoid a destructive mistake.
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 states a specific action on a specific resource: it defines which questions are excluded from emails, and crucially clarifies that the tool manages *exclusions* rather than the question set itself, which disambiguates the slightly misleading name. It does not, however, name or differentiate itself from sibling tools such as get_quiz_email_settings or save_quiz_email_template.
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?
Usage context is implied (default = all questions included, use this to hide specific ones), but there is no explicit when-to-use/when-not guidance and no mention of adjacent tools like toggle_quiz_email or save_quiz_email_template. Adequate but leaves the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Меняет адрес публичной ссылки на опрос — ту её часть, которую видит респондент. Занятый адрес не подменяется молча: инструмент откажет. Со старого адреса заводится переадресация, поэтому уже разосланные ссылки продолжают работать. Свой адрес ссылки доступен не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | Новый адрес, от 3 до 255 символов. Лучше короткий и понятный: он попадёт в ссылку. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say not-read-only, not-idempotent, not-destructive. The description goes well beyond: a taken address causes an explicit refusal rather than a silent overwrite, the old address gets a redirect so already-distributed links keep working, and the feature is tariff-gated. These are exactly the side effects and failure modes an agent needs.
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?
Four short sentences, front-loaded with what changes, then the collision behavior, then the redirect side effect, then the tariff caveat. Every sentence carries distinct information with no repetition.
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 two-parameter mutation with no output schema, the description covers the key behaviors: refusal on collision, redirect preservation, and availability constraints. It stops short of stating what the call returns or whether the change can be undone, but nothing critical is missing.
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?
Schema coverage is 100%, so both quiz_id and uri are fully documented in the schema (including the 3–255 length and the advice to keep it short). The description adds no syntax or format detail beyond that, so the baseline 3 is appropriate.
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?
States a specific verb+resource: changing the public quiz link address, explicitly narrowed to 'the part the respondent sees'. That is clear enough to act on, but it never distinguishes itself from adjacent siblings like manage_quiz_unique_links, manage_quiz_qr_code, or publish_quiz, so an agent must infer the boundary.
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?
The context of use is implied (you change the public link when you want a different address), and it surfaces a real prerequisite — a custom link address is not available on every tariff. However, there is no explicit when-to-use/when-not or pointer to an alternative tool for related link operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Задаёт, какие папки видит участник. Список передаётся целиком и заменяет прежний: передали три папки — участник видит ровно их. Пустой список открывает все папки аккаунта.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | ID участника (member_id из get_workspace_members). | |
| folder_ids | Yes | ID папок целиком, прежний список заменяется. Пустой список означает доступ ко всем папкам аккаунта — они будут назначены поимённо. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, covering the safety profile. The description adds that the list is fully replaced and an empty list opens all folders, but this information is already present in the schema's parameter descriptions, so it provides little beyond what structured data already offers.
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?
The description is three short sentences, front-loaded with the core purpose and followed by the key replacement semantics. Every sentence is relevant and there is no filler.
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 three-parameter mutation tool with full schema coverage and annotations covering safety, the description is largely complete. It explains the core behavior and edge case, though it omits any mention of permissions required or potential side effects beyond the replacement.
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?
Schema description coverage is 100%, so the schema fully documents all three parameters, including the replacement semantics and empty-list behavior. The description repeats this information without adding syntax, format, or other meaning 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 states a specific verb ('Задаёт') and resource ('какие папки видит участник'), making the tool's purpose clear. It does not explicitly differentiate from sibling tools like manage_folder_access or manage_workspace_folder, so it falls short of a 5.
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?
The description implies usage by explaining the replacement behavior and that an empty list opens all folders, but it does not state when to use this tool versus alternatives or any exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Меняет роль участника — то есть то, что он может делать в аккаунте. Действует сразу. Роль берётся из этого же аккаунта (из get_workspace_roles).
| Name | Required | Description | Default |
|---|---|---|---|
| role_id | Yes | ID новой роли (из get_workspace_roles). | |
| member_id | Yes | ID участника (member_id из get_workspace_members). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-readonly, non-destructive, non-idempotent mutation. The description adds one genuinely new behavioral detail — 'Действует сразу' (takes effect immediately) — but omits what happens to prior permissions, whether the member is notified, or any permission prerequisites.
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?
Three short sentences, front-loaded with the core action and effect. No filler, though the parenthetical role-source note partly repeats the schema.
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 3-param mutation tool with full annotation coverage and no output schema, the description covers what changes, that it applies immediately, and where the role comes from. Adequate, with only minor gaps around permissions and notification side-effects.
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?
Schema coverage is 100%, so all three params are already documented in the schema (including the get_workspace_roles source). The description's mention of the role source duplicates rather than extends the schema, landing at the baseline 3.
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?
States a specific verb+resource ('Меняет роль участника') and clarifies the effect ('то, что он может делать в аккаунте'), which separates it from sibling tools like remove_workspace_member and invite_workspace_member. However, it does not explicitly distinguish itself from set_workspace_member_folders, so differentiation is only implied.
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?
The description points to where the role_id comes from ('из get_workspace_roles'), which is useful context, but gives no explicit when-to-use vs when-not guidance and no alternatives. Usage is only implied from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавляет/синхронизирует теги для выбранного ответа респондента.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Массив строковых тегов (каждый max 250 символов). Заменяет существующие теги. | |
| quiz_id | Yes | ID опроса. | |
| answer_id | Yes | ID ответа. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare that this is a non-readOnly, non-destructive write operation, so the description's 'adds/synchronizes' wording adds some operational context. However, it does not disclose that the tags parameter replaces existing tags, nor does it clarify idempotency or return behavior.
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?
The description is a single, front-loaded sentence with no wasted words. It states the action and scope immediately, which is appropriate for a concise tool definition.
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 mutation tool with three required parameters, complete schema coverage, and annotations, the description covers the basic operation. It is still missing routing guidance against sibling tag tools, which would help the agent select it correctly.
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?
Schema coverage is 100%, so all three parameters are documented in the schema, including the crucial note that the tags array replaces existing tags. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.
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 gives a specific verb and resource: adding/synchronizing tags for a selected respondent answer. It is clear enough to identify the operation, but it does not explicitly distinguish itself from nearby siblings such as create_answer_tag, delete_answer_tag, or get_answer_tags.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer that it should be chosen for bulk tag assignment rather than create/delete/get tag operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Исключает ответ из отчётов и сводки или возвращает его обратно. В списке ответов он остаётся виден.
| Name | Required | Description | Default |
|---|---|---|---|
| is_hide | Yes | true — не учитывать ответ в отчётах и сводке, false — учитывать. | |
| quiz_id | Yes | ID опроса. | |
| answer_id | Yes | ID ответа. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real value beyond them: it discloses that the operation is reversible (a toggle), that it affects reports and summary specifically, and that the answers list is unaffected — exactly the kind of side-effect boundary an agent needs. Missing only permission/auth requirements.
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?
Two short sentences with zero filler; the primary effect is front-loaded and the scope caveat follows immediately. Every sentence carries information.
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 simple 3-parameter boolean toggle with full schema coverage and no output schema, the description covers purpose, direction, and scope boundary. It does not mention what the call returns or confirm whether repeated toggling is safe, but nothing essential for correct invocation is missing.
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?
Schema description coverage is 100% and is_hide is already documented in the schema as 'true — exclude from reports and summary, false — include.' The description restates the same hide/unhide semantics generically without adding format, default, or interaction detail beyond the schema, so the baseline of 3 applies.
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 names a specific verb (excludes/returns) and resource (the answer's presence in reports and summary), and it explicitly bounds the effect with 'В списке ответов он остаётся виден.' An agent can distinguish this from read tools like get_quiz_answers or other toggles (toggle_quiz_webhook, toggle_quiz_email) without opening any schema.
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?
It makes clear the tool is bidirectional (hide or un-hide) and clarifies the scope boundary — the answer stays visible in the answers list — which tells the agent when this is the right tool versus a read/export tool. It does not, however, state prerequisites, permissions, or name any alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Включает или выключает письма опроса: owner — уведомление автору о новом ответе, client — копия ответа респонденту. Копия респонденту доступна не на всех тарифах. Повторный вызов с тем же значением ничего не меняет.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | owner — письмо автору, client — копия респонденту. | |
| enabled | Yes | true — включить, false — выключить. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description asserts 'Повторный вызов с тем же значением ничего не меняет' — i.e. that repeated identical calls are no-ops — while the annotations declare idempotentHint: false. That directly contradicts the structured hint an agent relies on and would mislead it about re-invocation safety; the genuine value it adds (per-recipient semantics, tariff gating) does not offset the conflict.
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?
Three short sentences, front-loaded with the core action and then the mode meanings and the tariff caveat; there is little filler. Structure is efficient and every clause carries information, though the final idempotency clause is not just wasted but harmful.
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 simple 3-required-parameter write tool with no output schema, the description covers the action, both mode semantics, and a real business constraint (tariff gating), which is enough for an agent to call it. The gap is resource/lifecycle context (its relationship to the email-recipient and email-settings siblings) rather than core behavior.
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?
Schema description coverage is 100% and the enum values for `type` are already documented in the schema ('owner — письмо автору, client — копия респонденту'). The description only restates that mapping rather than adding syntax, defaults, or constraints (e.g. what happens to `enabled` if the tariff does not permit client mail), so baseline 3 applies.
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?
States a specific verb+resource ('Включает или выключает письма опроса') and then disambiguates the two modes, owner (author notification on new response) and client (copy to respondent). This is clear and more specific than a bare toggle, but it never names the sibling it must not be confused with (e.g. toggle_quiz_email_recipient), so full sibling differentiation is missing.
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?
Usage is only implied: the tariff note ('Копия респонденту доступна не на всех тарифах') is a precondition and the repeat-call note is a re-invocation caveat, but there is no explicit when-to-use guidance or routing to an alternative tool (save_quiz_email_template, toggle_quiz_email_recipient, etc.).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Включает или выключает конкретный адрес в уведомлениях автору. Работает только с подтверждённым адресом; число одновременно включённых адресов ограничено тарифом.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| email_id | Yes | ID адреса (из get_quiz_email_settings). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds genuine context beyond them: the confirmed-address precondition and the tariff-imposed limit on simultaneously enabled addresses, both of which affect whether a call succeeds.
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?
Two tight sentences, front-loaded with the purpose, then the constraints. No filler and every clause carries information.
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 two-parameter toggle with no output schema and annotations covering safety, the description covers purpose, precondition, and quota limit adequately. It leaves slight ambiguity about the direction of the toggle (whether it flips state or how on/off is selected), but nothing critical is missing.
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?
Schema coverage is 100%, so both parameters are already documented. The description only adds that the address must be confirmed and already exists, which is marginal beyond what the schema states (email_id 'from get_quiz_email_settings'). Baseline 3 is appropriate.
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 states a specific verb (enables/disables) and resource (a specific address in author notifications), so the agent knows exactly what the tool manipulates. It does not name the sibling tools it competes with (add/confirm/delete_quiz_email_recipient), so it falls short of full sibling differentiation.
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?
It gives a real precondition — the tool only works with a confirmed address — which implicitly routes the agent to confirm_quiz_email_recipient first. It does not explicitly name that alternative or state when to prefer this over adding/removing, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Включает или выключает вебхук. Выключенный остаётся настроенным, но отправки по нему не идут. После серии неудач вебхук отключается сам — включить обратно можно здесь же, когда приёмник починили.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса. | |
| is_active | Yes | true — включить, false — выключить. | |
| webhook_id | Yes | ID вебхука (из get_quiz_webhooks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (readOnly=false, idempotent=false, destructive=false); the description adds real value by explaining that a disabled webhook remains configured, that no deliveries occur, and that the platform auto-disables it after repeated failures. It does not address the idempotentHint=false claim for what is arguably an idempotent set-to-value operation.
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?
Three short sentences, front-loaded with the core action and followed by the two facts an agent needs. No filler or repetition.
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 three-parameter toggle with no output schema, the description covers the operation, the state semantics and the recovery path adequately. It omits any note on required permissions or what a successful response looks like, which are minor given the annotations.
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?
Schema description coverage is 100%, so all three parameters (quiz_id, webhook_id, is_active) are already documented in the schema, including the true/false meaning of is_active and the webhook_id lookup source. The description adds behavioral context but no parameter-level detail 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?
States a specific verb+resource pair ('Включает или выключает вебхук') and immediately clarifies the semantics of the off state, which cleanly separates it from siblings like create_quiz_webhook, update_quiz_webhook and delete_quiz_webhook. An agent can identify the operation without opening the schema.
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?
It supplies a genuine usage scenario — re-enabling a webhook that auto-disabled after delivery failures once the receiver is fixed — but never contrasts itself with update_quiz_webhook, which presumably can also change active state, and gives no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Занятость слота при переносе не проверяется: сначала посмотрите журнал через get_booking_journal. Изменяет запись: подтвердить, отменить, отметить неявку или перенести на другое время. Перенос требует обе границы — начало и конец. Респондент получит письмо, если в расписании включены уведомления.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | pending, confirmed, cancelled или no_show. | |
| comment | No | Комментарий к записи. | |
| end_utc | No | Новый конец встречи в UTC, передаётся вместе с началом. | |
| start_utc | No | Новое начало встречи в UTC, например 2026-10-01T09:00:00Z. Время без пояса тоже считается UTC. | |
| booking_id | Yes | ID записи (из get_booking_journal). | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-readonly, non-idempotent, non-destructive mutation. The description goes well beyond: it warns that slot conflicts are NOT validated, and that the respondent receives an email when schedule notifications are on — both material side effects an agent could not infer from the schema or 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?
Four sentences, front-loading the most important caveat (unchecked slot availability) before the operation list. Efficient, with only minor redundancy between the boundary requirement in the description and the schema.
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 mutation tool with no output schema, it covers operations, the reschedule invariant, a prerequisite read tool, and the notification side effect. Only the absence of any exclusions or a success/failure return note keeps it from being fully complete.
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?
Schema description coverage is 100%, so the schema already documents all six parameters with formats and the enum values. The description restates the start/end coupling requirement, which the schema already notes (передаётся вместе с началом), so it adds little beyond the structured fields.
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 names a specific verb (изменяет запись) and enumerates the exact operations available: confirm, cancel, mark no-show, reschedule. It is clearly distinguishable from sibling tools like create_booking_block or get_booking_journal.
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?
It gives a concrete prerequisite/alternative: slot availability is not checked on reschedule, so consult get_booking_journal first. That is strong actionable context, though it offers no explicit exclusions or comparison against other mutation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет логические условия опроса: условные переходы между виджетами, переходы по умолчанию, логику по баллам (score). Новый формат: score-правила идут в savedLogic как обычные группы с condition.score=true; legacy savedScoring сохраняется только для backward compatibility. group.actionType ∈ {"jump","screenout","show","hide"} ("show"/"hide" — логика видимости: jumpTo указывает виджет, который показывается или скрывается, а не следующий шаг маршрута; дополнительные цели — в visibilityActions). defaultConditions разрежен: запись нужна только там, где переход отличается от следующего вопроса по порядку. Все идентификаторы виджетов (widget_id, widgetId, jumpTo и т.д.) — те же уникальные UUID, что в quiz://{id}/structure (поле ids или ids внутри child-элементов inline_group). Перед вызовом прочитайте quiz://{id}/structure и используйте id без изменений. Обновление частичное: переданная карта заменяет одноимённую целиком (пустой объект очищает её), не переданные карты остаются как были. Служебные ключи conditions ведёт бэкенд: isQuota выводится из наличия групп дисквалификации по квоте, defaultConditionsVersion=2 проставляется при передаче defaultConditions — присылать их не нужно и нельзя. Валидация: проверка существования виджетов, корректности операторов, отсутствия циклов и тупиков в маршруте. Блокируют сохранение также противоречивые действия внутри одной группы: показ и скрытие одного вопроса, переход на вопрос, который эта же группа скрывает, и изменение видимости уже пройденного вопроса. В поле warnings возвращаются переходы назад, вопросы без входящих путей, правила-дубли перехода по умолчанию, условия по ответу вопроса ниже по порядку, порядок carry-forward и риски случайной сортировки вопросов — сохранению они не мешают.
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ID опроса для обновления логики. | |
| savedLogic | No | Группы условий переходов по widget_id (включая score-правила: condition.score=true, операторы 1/2/7/8/9/10, answer.optionId — порог totalScore). group.actionType: "jump" или "screenout". Источник баллов — пара condition.scoreSourceType ("survey" | "widget") и condition.scoreSourceWidgetId (UUID при "widget", null при "survey"). Отсутствие обоих полей = legacy "survey". Для условий на allocation_slider передайте allocationData.optionId — UUID из allocationSliderIds виджета; runtime сравнит значение этой опции с answer.optionId. | |
| savedScoring | No | Legacy-формат переходов по scoring (для backward compatibility). По ключам widget_id — объекты scoreConditionId→{score,jumpTo,inCase,inCaseMeaning}. Глобальные ключи: scoringEnabledWidgets, correctAnswers, scoringSwitcher. Для нового контента используйте savedLogic + score:true. | |
| multiLogicFlags | No | Флаги мульти-логики: {widget_id: boolean}. | |
| defaultConditions | No | Переходы по умолчанию по widget_id. | |
| savedInlineGroupLogic | No | Показ и скрытие вопросов внутри inline-группы, по widget_id самой группы: [{ conditionGroupId, actions: [{action: "show"|"hide", targetWidget: {widgetId}}], conditionsData: [...] }]. Без actionType и jumpTo — маршрута внутри группы нет. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-idempotent mutation, but the description adds far more: partial-update semantics (a passed map replaces the same-named map wholesale, an empty object clears it, unpassed maps persist), backend-managed keys (isQuota, defaultConditionsVersion) that must not be sent, validation rules (widget existence, operator validity, cycle/dead-end detection), blocked cases, and the warnings returned without blocking the save.
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?
Length is justified by a genuinely complex nested payload, and the purpose is front-loaded before the format, ID, update-semantics, validation, and warnings detail. The cost is structure: everything is crammed into one dense paragraph spanning several distinct topics, which hurts scannability.
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 six-parameter mutation tool with deeply nested objects and no output schema, the description supplies the missing return behavior (the warnings field), the format migration story, the ID contract, and the validation/blocking rules. An agent has enough to build a valid call and predict the outcome.
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?
Though schema coverage is 100%, the description adds meaning the schema cannot convey: group.actionType show/hide is visibility logic where jumpTo names the shown/hidden widget rather than the route step, defaultConditions is sparse, and score rules belong in savedLogic as ordinary groups with condition.score=true. These are genuine semantic clarifications beyond the field definitions.
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 opens with a specific verb and resource: it saves quiz logic conditions — conditional widget transitions, default transitions, and score logic — and distinguishes the new savedLogic format from the legacy savedScoring path. The scope is unambiguous. It does not, however, explicitly contrast itself with siblings such as update_quiz_widgets or update_quiz_settings, leaving the boundary to inference.
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?
It gives concrete workflow guidance: read quiz://{id}/structure first and reuse widget UUIDs unchanged, and use savedLogic + score:true for new content rather than legacy savedScoring. This is real operational context. It stops short of stating when to prefer this tool over adjacent update_* tools or any 'when not to use' exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавляет или изменяет внутреннюю заметку опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | Текст внутренней заметки опроса (видна только владельцу). | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is largely covered. The description adds that the note is internal and that the operation can create or modify it, but it does not explain overwrite behavior, permissions, or return effects.
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?
The definition is a single front-loaded sentence with no redundant or filler content. Every word contributes to stating the tool's purpose.
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 low-complexity, two-parameter mutation tool with full schema coverage and annotations covering the safety profile, the description is largely sufficient. It could be improved with usage context or result behavior, but little is missing given the surrounding structured metadata.
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?
Schema description coverage is 100%, and both parameters are documented in the schema, including that notes are visible only to the owner. The description adds no parameter-level syntax, format, or length details beyond what the schema already provides, so the baseline of 3 is appropriate.
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 states a specific verb ('добавляет или изменяет') and a specific resource ('внутреннюю заметку опроса'), so the agent can tell it is a note-upsert tool rather than a general quiz settings updater. It does not explicitly differentiate itself from nearby siblings such as update_quiz_texts or update_quiz_settings, which keeps it from a 5.
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?
The description provides no when-to-use guidance, prerequisites, or alternatives. It does not say when to choose this tool over update_quiz_texts, update_quiz_settings, or set_answer_note, leaving usage entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Обновляет настройки опроса (название, язык, отображение, навигация, ограничения по времени и числу ответов, капча, тема, скрипты, QR-код, таймер заполнения, IP/устройства, расписание доступа, аналитика и пиксели, SSO, анонимные ответы, категорийный скоринг и др.). Передаются только те поля, которые нужно изменить; остальные не трогаются.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Язык интерфейса опроса: ru, en, es или pt. | |
| name | No | Название опроса (макс. 255 символов). | |
| quiz_id | Yes | ID опроса, настройки которого нужно изменить. | |
| theme_id | No | ID темы оформления воркспейса (целое ≥ 1). | |
| info_title | No | Заголовок (мета, макс. 500 символов). | |
| numeration | No | Включить нумерацию вопросов. | |
| sso_active | No | Требовать вход через SSO перед прохождением опроса. | |
| description | No | Описание опроса (мета, макс. 5000 символов). | |
| multiple_ip | No | Разрешить прохождение с нескольких IP (иначе один IP на прохождение). | |
| show_by_one | No | Показывать по одному вопросу на экране. | |
| extra_fields | No | Список скрытых переменных (extra fields): массив объектов с полями id (UUID) и name (макс. 250 символов). | |
| ip_blacklist | No | Чёрный список IP (макс. 5000 символов). | |
| ip_whitelist | No | Белый список IP (макс. 5000 символов). | |
| qr_code_size | No | Размер QR-кода в пикселях (1–1000). | |
| show_captcha | No | Показывать капчу при отправке ответа. | |
| use_password | No | Требовать пароль для доступа к опросу. | |
| fb_pixel_code | No | Идентификатор пикселя Facebook (макс. 100 символов). | |
| qr_code_color | No | Цвет QR-кода (макс. 50 символов). | |
| schedule_days | No | Дни недели, в которые опрос доступен: массив чисел 1–7 по ISO (1 — понедельник, 7 — воскресенье). | |
| show_navigate | No | Показывать навигацию (кнопки назад/вперёд). | |
| vk_pixel_code | No | Идентификатор пикселя VK (макс. 100 символов). | |
| qr_code_format | No | Формат файла QR-кода: png, svg или eps. Это запомненная настройка опроса; сам код собирает manage_quiz_qr_code. | |
| qr_code_margin | No | Отступ QR-кода (0–100). | |
| show_to_robots | No | Доступность страницы опроса для поисковых роботов. | |
| correct_answers | No | Показывать и использовать корректные ответы для тестового сценария. | |
| ip_list_enabled | No | Включить фильтрацию по спискам IP (белый/чёрный список). | |
| is_change_theme | No | Менять тему оформления по данным из QR-кода. | |
| quiz_categories | No | Список категорий для категорийного скоринга: массив объектов { "id": "<строка>", "name": "<название>" }. Порядок значим: при равенстве баллов побеждает категория, идущая раньше. Веса категорий задаются у опций виджетов, а не здесь. | |
| scripts_in_body | No | Код скриптов, вставляемых в <body> (макс. 65535 символов). Хранится без санитизации — ответственность за безопасность содержимого на стороне рендерера. | |
| scripts_in_head | No | Код скриптов, вставляемых в <head> (макс. 65535 символов). Хранится без санитизации — ответственность за безопасность содержимого на стороне рендерера. | |
| category_scoring | No | Включить категорийный скоринг: баллы опций суммируются по категориям, победившая категория пишется в ответ. | |
| limit_time_value | No | Дата/время окончания доступности (макс. 50 символов; пустая строка — сброс). | |
| matrix_transpose | No | Транспонировать матричные вопросы в отчёте: строки и столбцы меняются местами. | |
| schedule_enabled | No | Включить доступ к опросу по расписанию (дни недели + интервал времени). | |
| schedule_time_to | No | Конец интервала доступности в формате H:i (например "18:00"). Трактуется в таймзоне schedule_timezone. | |
| scoring_switcher | No | Включить переключатель подсчёта баллов в опросе. | |
| show_progressbar | No | Показывать прогресс-бар прохождения опроса. | |
| sso_allow_retake | No | Разрешать SSO-респонденту пройти опрос повторно. | |
| available_devices | No | Доступные устройства: массив из desktop, mobile, tablet. | |
| schedule_timezone | No | Таймзона расписания, идентификатор IANA (например "Europe/Moscow"). | |
| answers_allow_edit | No | Разрешить респонденту редактировать уже отправленный ответ. Работает только вместе с SSO (sso_active) или подтверждением e-mail (require_email_verification) — иначе ссылка на редактирование не выдаётся. | |
| auto_move_by_enter | No | Переход к следующему вопросу по нажатию Enter. | |
| auto_save_progress | No | Автосохранение прогресса: респондент может вернуться и продолжить с того же места. | |
| captcha_public_key | No | Публичный ключ капчи (макс. 500 символов). | |
| captcha_secret_key | No | Секретный ключ капчи (макс. 500 символов). | |
| close_quiz_enabled | No | Опрос закрыт (приём ответов отключён). | |
| fb_pixel_is_active | No | Включить пиксель Facebook. | |
| limit_message_body | No | Текст сообщения при достижении лимита ответов (макс. 5000 символов). | |
| limit_time_enabled | No | Включить ограничение по времени доступности опроса. | |
| report_row_options | No | Настройки строк отчёта: sort_mode (default, asc, desc) и value_format (both, count, percent). null возвращает стандартное поведение. | |
| results_appearance | No | Оформление отчёта этого опроса: palette_id, custom_colors, bar_color_mode, font_family, show_value_labels, show_grid_lines. null возвращает стандартный вид. Передача этого объекта заодно выключает results_appearance_use_shared — иначе цвета не применились бы, потому что общая палитра аккаунта имеет приоритет. Допустимые значения и текущая палитра аккаунта: get_workspace_report_appearance. | |
| schedule_time_from | No | Начало интервала доступности в формате H:i (например "09:00"). Трактуется в таймзоне schedule_timezone. | |
| vk_pixel_is_active | No | Включить пиксель VK. | |
| anonymous_responses | No | Анонимные ответы: не сохранять данные, идентифицирующие респондента. | |
| limit_message_title | No | Заголовок сообщения при достижении лимита ответов (макс. 500 символов). | |
| limit_time_timezone | No | Таймзона для ограничения по времени (макс. 100 символов). | |
| limit_time_value_tz | No | Значение времени с таймзоной (макс. 50 символов). | |
| question_timer_mode | No | Таймер обратного отсчёта на вопрос: individual, all_enabled или all_disabled. | |
| filling_time_enabled | No | Включить таймер времени на заполнение опроса. | |
| filling_time_seconds | No | Время на заполнение в секундах (0–86400). | |
| question_random_mode | No | Что перемешивать при случайном порядке: all — всю анкету, groups — только вопросы, отмеченные полем randomGroupId (каждый набор перемешивается по своим позициям). По умолчанию all. | |
| session_check_method | No | Методы проверки сессии: массив из ip, cookie, extra_params. | |
| allow_multiple_answer | No | Разрешить повторную отправку ответа (несколько прохождений). | |
| disable_auto_redirect | No | Отключить автоматический переход после ответа. | |
| google_analytics_code | No | Идентификатор Google Analytics (макс. 100 символов). | |
| question_random_order | No | Показывать вопросы в случайном порядке. | |
| report_merge_versions | No | Склеивать версии вопросов в отчёте: ответы, собранные разными версиями опроса, показываются одним блоком. | |
| yandex_analytics_code | No | Номер счётчика Яндекс.Метрики (макс. 100 символов). | |
| allow_restart_progress | No | Разрешить вернувшемуся респонденту начать прохождение заново вместо продолжения незавершённого. Работает только вместе с auto_save_progress. | |
| question_min_view_mode | No | Минимальное время просмотра вопроса перед переходом вперёд: individual, all_enabled или all_disabled. | |
| question_required_mode | No | Режим обязательности вопросов: individual, all_required или all_optional. | |
| question_timer_seconds | No | Длительность таймера вопроса в секундах (при question_timer_mode=all_enabled). | |
| limit_answer_count_mode | No | Что считать за ответ в лимите: all (все записи, включая брошенные), completed (завершённые вместе с отсеянными), completed_no_screenout (завершённые без отсеянных). Дефолт новых опросов — completed. | |
| scripts_in_body_enabled | No | Включить выполнение скриптов в body. | |
| scripts_in_head_enabled | No | Включить выполнение скриптов в head. | |
| google_analytics_version | No | Версия Google Analytics (макс. 20 символов). | |
| limit_answer_count_value | No | Максимальное число ответов (0–1000000). | |
| qr_code_background_color | No | Цвет фона QR-кода (макс. 50 символов). | |
| block_jump_to_prev_widget | No | Запретить переход к предыдущему вопросу (виджету). | |
| question_lock_answer_mode | No | Запретить изменение ответа после ответа: individual, all_enabled или all_disabled. | |
| question_min_view_seconds | No | Минимальное время просмотра в секундах (при question_min_view_mode=all_enabled). | |
| google_analytics_is_active | No | Включить отправку событий в Google Analytics. | |
| limit_answer_count_enabled | No | Включить ограничение максимального числа ответов (прохождений). | |
| multilogic_sequential_mode | No | Последовательная мульти-логика: несколько групп условий одного вопроса применяются по порядку, а не только первая сработавшая. | |
| question_timer_button_mode | No | Показывать вопрос по кнопке: individual, all_enabled или all_disabled. | |
| require_email_verification | No | Требовать подтверждение e-mail перед отправкой ответа. | |
| yandex_analytics_is_active | No | Включить отправку событий в Яндекс.Метрику. | |
| closed_quiz_message_enabled | No | Включить сообщение о закрытии опроса. | |
| yandex_analytics_is_webvisor | No | Включить Вебвизор в Яндекс.Метрике. | |
| results_appearance_use_shared | No | Следовать общей палитре отчётов аккаунта (update_workspace_report_palette). true — опрос рисует отчёты палитрой аккаунта; свои цвета опроса остаются на месте и вернутся, если выключить. | |
| anonymous_responses_show_label | No | Показывать респонденту пометку о том, что опрос анонимный. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false), so the description is not the sole carrier of safety information. It still adds real behavioral context beyond the annotations: unspecified fields are preserved, which tells the agent it can update one setting without clobbering others. It stops short of covering auth needs, side effects of enabling scripts/pixels, or any rate/consistency behavior.
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?
Two sentences total for a 91-parameter tool, with verb+resource front-loaded and the behavioral rule (partial update) placed after the scope list. The domain enumeration is long but functional — it bounds a very large surface — and no sentence is redundant.
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?
Given the tool's size, the description adequately conveys scope plus the key mutation semantic. The remaining gap is modest: with no output schema, it says nothing about what the call returns or how array-valued settings (extra_fields, quiz_categories, available_devices) behave on update versus merge, but return values for a settings updater are largely predictable.
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?
Schema description coverage is 100%, so the schema already documents all 91 parameters, including constraints, enums and cross-field caveats. The description's parenthetical grouping of domains adds orientation but no syntax, format or dependency information beyond what the schema supplies, so the baseline 3 applies.
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?
States a specific verb and resource ('Обновляет настройки опроса') and enumerates the setting domains it covers (display, navigation, limits, captcha, theme, scripts, QR, schedule, analytics, SSO, scoring, etc.), so an agent knows this is the general settings-mutation tool. It does not, however, disambiguate against overlapping siblings such as rename_quiz, apply_quiz_theme, manage_quiz_analytics or manage_quiz_passwords, so an agent may still have to guess which surface owns a given setting.
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?
The second sentence gives a genuinely useful operational rule ('only the fields to change are passed; the rest are untouched'), which tells the agent this is a partial/PATCH-style update. There is no explicit when-to-use-vs-alternative guidance, no prerequisites (e.g. auth, publish state), and no statement about which sibling tools own the settings that overlap this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет пользовательские тексты кнопок и интерфейсных элементов опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | Массив объектов {code, text}. code — строковый ключ текста (например "button_next", "button_send"). text — новое значение (пустая строка сбросит к дефолту). Актуальные коды возвращает ресурс quiz://{id}/texts. | |
| quiz_id | Yes | ID опроса. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is not read-only and not destructive. The description adds that it saves custom button and interface texts, which is slightly more specific than the annotation's generic write hint, but it omits non-idempotence, permission requirements, and what happens on reset beyond the schema's mention.
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?
A single front-loaded sentence with zero waste. It is appropriately sized for a simple update tool.
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?
Given the rich input schema (100% coverage, detailed examples, and a reference to the quiz://{id}/texts resource) and the presence of annotations, the terse description is largely sufficient. It could optionally mention usage context, but the surrounding structured data fills the main gaps.
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?
Schema description coverage is 100%, so the schema fully documents both parameters, including examples and reset semantics. The description itself adds no parameter-level detail, which is acceptable given the high coverage.
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 states a specific verb (Сохраняет) and resource (пользовательские тексты кнопок и интерфейсных элементов опроса), making clear what the tool does. It does not explicitly differentiate from the read-only sibling get_quiz_texts or other update tools, but the purpose is unambiguous.
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 guidance is provided on when to use this tool versus alternatives. The description only asserts what it does; it offers no context about prerequisites, when to call it, or how it relates to get_quiz_texts or other quiz-setting updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Обновляет имя скрытой переменной опроса.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Новое имя переменной. | |
| quiz_id | Yes | ID опроса. | |
| field_id | Yes | UUID скрытой переменной. Взять из quiz://{id}/variables. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing further — no statement about permissions, whether the old name is recoverable, or what a rename affects in live quizzes; and it largely repeats what the schema already says about the hidden variable.
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?
A single front-loaded sentence with no filler. It is efficient, though at this length it veers toward under-specification rather than true brevity.
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 simple single-attribute rename with a fully documented three-parameter schema and no output schema, the essentials are present. What is missing is any routing guidance among the many sibling variable/option tools and any note on effects or constraints, leaving it merely adequate.
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?
Schema description coverage is 100%: quiz_id, field_id (including where to obtain the UUID) and name are all documented in the schema. The description contributes no additional parameter semantics, so the baseline 3 applies.
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?
States a specific verb and resource ('Обновляет имя скрытой переменной опроса'), and narrows scope to a single attribute (name) of a hidden variable. It does not, however, distinguish itself from adjacent siblings such as create_quiz_variable, delete_quiz_variable or update_hidden_option, so the agent must rely on the name alone.
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 when-to-use guidance, no prerequisites, and no mention of the alternative tools for the same resource. The schema hint about pulling field_id from quiz://{id}/variables is the only procedural cue, and it lives in the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Изменяет вебхук опроса. Не переданные поля сохраняют текущие значения, поэтому можно слать только то, что меняется. Идентификатор вебхука — из get_quiz_webhooks.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Адрес, куда уходят данные. Только публичный http или https. | |
| body | No | Шаблон отправляемых данных: какие поля ответа слать. | |
| hours | No | Задержка перед отправкой в часах: 0, 1, 6, 12 или 24. | |
| title | No | Название вебхука, до 255 символов. | |
| method | No | HTTP-метод: get, post, put или patch. | |
| headers | No | Дополнительные заголовки запроса, список из {"name": "...", "value": "..."}. | |
| quiz_id | Yes | ID опроса. | |
| is_active | No | Включён ли вебхук. | |
| incomplete | No | Слать и незавершённые ответы. | |
| webhook_id | Yes | ID вебхука (из get_quiz_webhooks). | |
| body_naming | No | Переименование полей: свой ключ для каждого поля отправки. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it a non-read-only, non-destructive, non-idempotent mutation. The description adds genuinely useful behavior beyond that: unset fields retain their current values, so it is a partial-update patch semantics, not a full replacement. It does not cover auth requirements or rate limits, but the partial-update disclosure is the key risk-relevant fact.
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?
Three short sentences, front-loaded with the purpose, then the partial-update behavior, then the ID source. No filler; every sentence carries information the agent needs.
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 mutation tool with annotations covering safety and a fully documented schema, the description is nearly complete: it states purpose, update semantics, and ID provenance. Return behavior is not described, but with no output schema and read-only/expected diff not being a concern, this is a minor gap.
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?
Schema description coverage is 100%, so the schema already documents all 11 params (including the enums and nested objects), establishing the baseline of 3. The description adds the partial-vs-full update meaning for unspecified params but no per-parameter detail 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?
States a specific verb ("Изменяет") plus resource ("вебхук опроса"), and points to get_quiz_webhooks as the ID source. It clearly identifies the operation, but does not explicitly contrast with near siblings like create_quiz_webhook, delete_quiz_webhook, or toggle_quiz_webhook.
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?
Explains the partial-update contract ("можно слать только то, что меняется"), which governs how to invoke the tool, and tells the agent where to obtain webhook_id. It gives clear context but no explicit when-not conditions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сохраняет структуру виджетов опроса (ids + entities). Перед вызовом прочитайте текущую структуру через ресурс quiz://{id}/structure. ids — массив идентификаторов виджетов по порядку; entities — объект конфигов по этим id. ВАЖНО: идентификаторы виджетов — уникальные UUID в формате RFC 4122 (например 550e8400-e29b-41d4-a716-446655440000). Допустимы только служебные строки "welcome" (первый) и "submit" (последний); все остальные id обязаны быть уникальными UUID. При добавлении новых виджетов генерируйте новый UUID для каждого; дубликаты id запрещены. Экран благодарности («спасибо», thank you) — это ОТДЕЛЬНЫЙ виджет type = "finish" с новым UUID перед "submit"; правка полей submit его не создаёт. Спецварианты «Другое / Свой вариант», «Затрудняюсь ответить», «Ничего из перечисленного» включаются флагами choiceTextOther / dropdownOther / hardToAnswer / noneOfAbove, а не добавляются пунктами в список вариантов. Ответ инструмента содержит фактически сохранённый состав (saved: количество виджетов и разбивка по типам) — сверьтесь с ним, прежде чем отвечать пользователю, что изменение применилось.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Порядок виджетов: "welcome", затем уникальные UUID виджетов, затем "submit". Каждый id — уникальный UUID (кроме welcome/submit). | |
| quiz_id | Yes | ID опроса для обновления. | |
| entities | Yes | Конфигурации виджетов: ключ — UUID из ids (уникальный для каждого виджета). Идентификаторы вариантов внутри виджета (choiceTextIds, dropdownIds, matrixRowIds и остальные списки опций) — тоже UUID, сгенерированные заново; порядковые имена вроде «q2_1» не годятся: опрос с ними сохранится, но публикация упадёт. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnly=false, destructive=false, idempotent=false) with high-value operational detail: UUID/RFC 4122 requirement, only 'welcome'/'submit' as non-UUID ids, the finish ('thank you') widget as a separate widget, flags vs. list items for special answers, and even the return shape ('saved: количество виджетов и разбивка по типам') despite no output schema. It tells the agent to verify the saved composition before confirming success — a real behavioral contract.
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?
Front-loads the one-line purpose, then layers the important warnings. It is dense but every clause carries a constraint (UUID format, special screens, flags, verification) relevant to a tool with nested objects. Slightly long, but no filler sentences.
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 3-parameter, write-mode tool with deeply nested entities and no output schema, the description covers the failure-prone essentials: id format, mandatory ordering, the separate finish widget, special-option flags, and result verification. Nothing critical is left to inference.
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?
Schema coverage is 100%, so the baseline is 3. The description nonetheless adds semantics beyond the schema: the ordering rule (welcome first, submit last, unique UUIDs between), the entities-keyed-by-id relationship, and the finish-widget requirement are surfaced as narrative guidance an agent must act on.
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?
States a specific verb+resource: 'Сохраняет структуру виджетов опроса (ids + entities)' — saving the quiz widget structure. It is clearly distinguishable from read-side siblings like get_quiz_structure and from update_quiz_settings/texts/logic. It stops short of explicitly naming a sibling, so it lands at 4 rather than 5.
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?
Provides one explicit precondition — 'Перед вызовом прочитайте текущую структуру через ресурс quiz://{id}/structure' — which is genuine workflow guidance. However, it never states when to choose this tool over update_quiz_texts, update_quiz_logic, or update_quiz_settings, so the alternative-selection guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Обновляет существующую тему в workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Название темы (опционально, max 255 символов). Если не передать — генерируется автоматически. | |
| bg_color | No | Цвет фона в формате #RRGGBB. Используется когда background_type_id=1. Например: #0f3460. | |
| theme_id | Yes | ID темы для обновления. Взять из theme://list или theme://{id}/details. | |
| base_font | No | Название базового шрифта строкой (например «Golos Text», «Montserrat»). Опционально, max 255 символов. Если пусто — используется дефолтный шрифт. | |
| custom_css | No | Свой CSS для страницы опроса, до 20000 символов. | |
| input_style | No | Стиль полей ввода: box — поле в рамке, underline — одна линия. | |
| base_font_id | No | ID базового шрифта. Популярные: 1=Native, 2=Roboto, 3=Open Sans, 4=Montserrat, 5=Source Sans Pro, 6=Merriweather, 9=PT Sans, 11=Ubuntu, 15=Rubik, 18=Comfortaa, 44=Golos Text. Полный список 1–44. | |
| header_color | No | Цвет заголовка в формате #RRGGBB. Например: #1a1a2e. | |
| heading_font | No | Отдельный шрифт заголовков, название гарнитуры Google Fonts. Пусто — шрифт как у остального текста. | |
| service_text | No | Служебный текст, до 500 символов. Простая разметка допустима, остальное вырезается. | |
| workspace_id | Yes | ID воркспейса. Взять из workspace://list. | |
| answer_border | No | Толщина рамки вариантов ответа в px (0–999). Например: 1. | |
| buttons_color | No | Цвет кнопок в формате #RRGGBB. Например: #3b82f6. | |
| buttons_radius | No | Скругление кнопок в px (0–999). Например: 8. | |
| progress_style | No | Индикатор прогресса: percent, line или steps. | |
| bg_gradient_end | No | Конечный цвет градиента в формате #RRGGBB. Например: #00ffd8. | |
| bg_logo_file_id | No | ID загруженного файла логотипа поверх фона (min:1). | |
| bg_logo_size_id | No | Размер логотипа на фоне: 0 — маленький, 1 — средний (по умолчанию), 2 — большой. | |
| buttons_type_id | No | Тип кнопок: 1=background (заливка цветом), 2=border (только рамка). | |
| container_width | No | Ширина содержимого: narrow, normal, wide или full. | |
| bg_image_file_id | No | ID загруженного файла фонового изображения (min:1). Используется когда background_type_id=1. | |
| bg_gradient_start | No | Начальный цвет градиента в формате #RRGGBB (ровно 6 hex-символов). Например: #00d4ff. | |
| button_full_width | No | Растянуть кнопку на всю ширину контейнера. | |
| dropdown_bg_color | No | Цвет фона раскрытого меню выпадающего списка в формате #RRGGBB (опционально). Если не передать — наследует bg_color. | |
| questions_size_id | No | Размер текста вопросов: 0 — маленький, 1 — средний, 2 — большой. | |
| service_text_size | No | Размер служебного текста: 12, 14 или 16. | |
| answers_text_color | No | Цвет текста ответов в формате #RRGGBB (опционально). Если не передать — наследует header_color. | |
| background_opacity | No | Прозрачность фона в процентах (0–100). 100 = непрозрачный. | |
| background_type_id | No | Тип фона: 1=color_image (цвет/изображение), 2=gradient (градиент). | |
| bg_gradient_vector | No | Направление градиента в градусах (0–360). Используется когда background_type_id=2. Пример: 90 = слева направо, 180 = сверху вниз. | |
| buttons_text_color | No | Цвет текста кнопок в формате #RRGGBB. Например: #ffffff. | |
| service_text_color | No | Цвет служебного текста в формате #RRGGBB. | |
| service_text_scope | No | Где показывать служебный текст: all — на всех экранах, welcome, questions или finish. | |
| background_contrast | No | Контраст фона (-100 – +100). 0 = без изменений. | |
| background_saturate | No | Насыщенность фона (-100 – +100). 0 = без изменений. | |
| bg_logo_position_id | No | Положение логотипа на фоне: 0 — слева (по умолчанию), 1 — по центру, 2 — справа. Нумерация своя, с background_position_id не совпадает. | |
| question_transition | No | Переход между вопросами: slide, fade, zoom, blur или none. | |
| widget_active_color | No | Цвет активного элемента виджета в формате #RRGGBB. Например: #e94560. | |
| background_lightness | No | Яркость фона (-100 – +100). 0 = без изменений. | |
| service_text_enabled | No | Показывать служебный текст — короткую строку для дисклеймера или согласия. | |
| answer_options_radius | No | Скругление вариантов ответа в px (0–999). Например: 4. | |
| questions_position_id | No | Выравнивание текста вопросов: 0 — слева, 1 — по центру. | |
| service_text_align_id | No | Выравнивание служебного текста: 0 — слева, 1 — по центру, 2 — справа. Справа работает только вместе с верхним размещением: внизу справа стоят стрелки навигации и бейдж WebAsk. | |
| background_position_id | No | Позиция фона: 1=center center, 2=left center, 3=right center, 4=center top, 5=left top, 6=right top, 7=center bottom, 8=left bottom, 9=right bottom. | |
| background_placement_id | No | Размещение фона: 1=stretch (растянуть), 2=drawin (вписать), 3=cover (заполнить). | |
| service_text_placement_id | No | Где на экране стоит служебный текст: 0 — снизу, 1 — сверху. | |
| welcome_and_finish_size_id | No | Размер текста на приветствии и завершении: 0 — маленький, 1 — средний, 2 — большой. | |
| welcome_and_finish_position_id | No | Выравнивание текста на приветствии и завершении: 0 — слева, 1 — по центру. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description is consistent with 'updates existing'. However, it adds nothing beyond them: it does not say whether this is a partial/patch update (only supplied fields change), what happens to the other 46 unspecified fields, or whether special permissions are required. For a 48-parameter mutation, that is a real gap.
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?
The single sentence is front-loaded and free of filler, but against a 48-parameter schema it reads as under-specification rather than disciplined conciseness. Nothing is wasted because almost nothing is said.
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 48-parameter mutation tool with no output schema and only a minimal safety annotation set, one sentence is wholly inadequate. It omits partial-update semantics, side effects, permission requirements, and any interaction with the many theme-related siblings.
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?
Schema description coverage is 100%, so every one of the 48 parameters is already documented with types, enums, ranges and examples. Per the rubric this sets a baseline of 3, and the description contributes no additional parameter meaning (e.g. patch-vs-replace semantics) to move it higher or lower.
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 states a specific verb and resource ('Обновляет существующую тему в workspace'), clearly distinguishing it from create_theme and get_theme_* siblings. It stops short of differentiating itself from the ambiguous manage_theme sibling, which an agent could equally reach for.
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?
There is no guidance on when to choose update_theme over manage_theme, create_theme, or apply_quiz_theme, and no prerequisites such as needing an existing theme_id or permissions. The agent is left to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Правка своего профиля: имя, язык интерфейса, часовой пояс, оформление и подписки на письма. Часовой пояс важен отдельно — от него зависят все даты в отчётах и выгрузках. Передавайте только те поля, которые нужно поменять; подписки можно менять по одной, остальные останутся как были. Смена почты и пароля здесь недоступна (там код из письма и текущий пароль), аватар тоже — это загрузка картинки. Прочитать профиль — user://me.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Язык интерфейса и писем: ru, en, es и другие коды. | |
| name | No | Имя, от 3 до 255 символов. У владельца аккаунта им же называются его аккаунты. | |
| theme | No | Оформление кабинета: light, dark или auto. | |
| timezone | No | Часовой пояс в виде Europe/Moscow. От него зависят даты в отчётах и выгрузках. | |
| subscribe_action | No | Письма о действиях в аккаунте. | |
| subscribe_billing | No | Письма об оплате и списаниях. | |
| subscribe_marketing | No | Письма с новостями и предложениями. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish a non-read-only, non-destructive mutation. The description adds partial-update behavior, the impact of timezone on report/export dates, and explicit boundaries around email, password, and avatar changes. This is meaningful behavioral context beyond the structured fields.
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?
It is front-loaded with the action and affected fields, then adds only necessary constraints and alternatives. Every sentence earns its place, with no redundant restatement of the name or schema.
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 7-parameter optional-update tool with full schema coverage and no output schema, the description is complete enough: it covers updatable fields, partial-update semantics, timezone side effects, unavailable operations, and the read alternative.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter update semantics ('Передавайте только те поля, которые нужно поменять') and highlights the special importance of timezone beyond what the individual schema descriptions provide.
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?
States a specific verb and resource ('Правка своего профиля') and enumerates the mutable fields: name, interface language, timezone, theme, and email subscriptions. It also distinguishes itself from the read-profile sibling by pointing to 'Прочитать профиль — user://me'.
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?
Explicitly says to pass only fields that need changing and that subscriptions can be changed one at a time while others remain as they were. It also names unavailable operations (email, password, avatar) and gives the read alternative, covering when to use this tool versus another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Настраивает брендинг рабочего пространства: показ логотипа и копирайта WebAsk. Настройки общие для всех опросов пространства. Скрытие копирайта доступно не на всех тарифах.
| Name | Required | Description | Default |
|---|---|---|---|
| logo_show | No | Показывать логотип рабочего пространства в опросах. | |
| workspace_id | Yes | ID рабочего пространства. Взять из workspace://list. | |
| show_copyright | No | Показывать копирайт WebAsk. Скрытие (false) доступно не на всех тарифах. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-destructive, non-idempotent write op. The description adds context the annotations cannot: the settings apply globally to all surveys in the workspace ('общие для всех опросов') and there is a plan-gated restriction on disabling the copyright. These are genuine behavioral disclosures beyond the structured hints.
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?
Three short, front-loaded sentences that state purpose, scope, and constraint with no wasted text. Each sentence carries distinct information.
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?
No output schema exists and annotations are present, so the description need not cover return values. It adequately covers what the tool configures, its global scope, and a plan limitation — sufficient for a simple three-parameter configuration tool.
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?
Schema description coverage is 100%, so the schema already documents all three parameters, including the plan caveat on show_copyright. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.
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 gives a specific verb ('Настраивает') and resource (workspace branding) and names the configurable aspects (logo and copyright display). It implicitly distinguishes itself from image-management siblings like upload_workspace_logo by focusing on display toggles, though it never names an alternative explicitly.
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?
It states a meaningful precondition — hiding the copyright is not available on all plans ('доступно не на всех тарифах') — which guides the agent. However, there is no clear when-to-use vs when-not-to-use guidance or routing to sibling tools, so usage is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Задаёт общую палитру отчётов аккаунта. Все опросы с results_appearance_use_shared = true сразу начинают рисовать отчёты ею, свои цвета опросов при этом не трогаются. Требуется право account_quiz_settings.
| Name | Required | Description | Default |
|---|---|---|---|
| settings | Yes | Объект оформления. Неизвестные значения приводятся к стандартным, а не отклоняют вызов. | |
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag it as a non-read-only, non-destructive write. The description adds real behavioral context beyond that: the blast radius (all shared-flag quizzes redraw immediately), the non-effect (own quiz colors preserved), and the auth prerequisite. It does not discuss reversibility or failure behavior.
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?
Three short sentences, front-loaded with the core action, followed by scope of effect and the permission requirement. No filler; every sentence carries information.
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 2-param mutation with full schema coverage, annotations, and no output schema, the description covers the essentials: action, scope, permission. Only minor gaps remain, such as what the agent should expect on invalid input or whether repeated calls are safe.
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?
Schema description coverage is 100%, with every nested field (palette_id, font_family, custom_colors, bar_color_mode, toggles) documented including the custom-palette rollback rule. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
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 states a specific verb+resource (sets the account's shared reports palette) and scopes it precisely: it applies to all quizzes with results_appearance_use_shared=true. This clearly distinguishes it from per-quiz theming siblings like apply_quiz_theme and from create_report_appearance_preset.
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?
It gives clear context (affects every quiz with the shared flag) and names the required permission (account_quiz_settings), plus clarifies that per-quiz colors are untouched, which implicitly routes away from quiz-level theming tools. It stops short of explicitly naming an alternative tool or a when-not-to-use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Загрузка медиа (изображение, видео или аудио) для блока multimedia любого виджета. Передайте type (image|video|audio) и url (ссылка) или file_base64 — файл сохраняется в хранилище, возвращается url. Подставьте url в update_quiz_widgets: multimedia.imgUrl, multimedia.videoUrl или multimedia.audioUrl. Укажите ровно один: url или file_base64.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Ссылка на файл. Скачаем и сохраним в хранилище. Укажите url или file_base64. | |
| type | Yes | Тип медиа: image, video или audio. | |
| quiz_id | Yes | ID опроса. | |
| filename | No | Имя файла с расширением (для file_base64). Опционально (image.jpg, video.mp4, audio.mp3). | |
| file_base64 | No | Содержимое в base64 (можно с префиксом data:...;base64,...). Укажите url или file_base64. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds valuable behavior beyond them: the file is downloaded and persisted to storage and a url is returned, plus the exactly-one source constraint. It stops short of explaining auth needs or the non-idempotent consequence of re-uploading.
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?
Three dense, front-loaded sentences: purpose, then how to call, then the downstream integration step. Every clause carries information (including the return value), with no filler.
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 mutation tool with no output schema, the description compensates by stating the return value (url saved to storage) and the follow-up integration. Combined with full annotation and schema coverage, an agent has enough to call it correctly; only sibling differentiation is missing.
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?
Schema coverage is 100%, so the baseline is 3 and the schema already documents each field. The description adds a constraint not encoded in the schema — that url and file_base64 are mutually exclusive ('ровно один') — which is genuinely useful disambiguation.
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 names a specific verb+resource (upload media — image/video/audio) and scopes it to the multimedia block of any widget, which is more precise than the title. It does not, however, distinguish itself from the very similar sibling upload_quiz_widget_image, leaving the agent to infer which image-upload path applies.
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?
It provides clear workflow context: pass type plus exactly one of url/file_base64, then substitute the returned url into update_quiz_widgets (multimedia.imgUrl/videoUrl/audioUrl). That tells the agent when the tool sits in a flow, but it offers no explicit exclusion against the similar upload_quiz_widget_image sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Загрузка изображения для виджета «выбор с медиа» (варианты ответа с картинкой). Передайте url (ссылка на картинку) или file_base64 (содержимое в base64) — файл сохраняется в хранилище, возвращается url. Подставьте полученный url в choiceImageEntities[].link в update_quiz_widgets. Укажите ровно один: url или file_base64.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Ссылка на изображение. Скачаем и сохраним в хранилище. Укажите url или file_base64. | |
| quiz_id | Yes | ID опроса. | |
| filename | No | Имя файла с расширением (для file_base64). Опционально, по умолчанию image.jpg. | |
| file_base64 | No | Изображение в base64 (можно с префиксом data:image/...;base64,...). Укажите url или file_base64. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-readonly, non-destructive, non-idempotent, closed-world write, so the burden is lighter. The description adds real behavior: the file is persisted to storage and a url is returned, plus the mutual-exclusivity input requirement. Auth, limits, and failure modes remain unstated.
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?
Three front-loaded sentences: purpose, input modes + resulting behavior/output, then downstream integration with the exclusivity rule. Every sentence earns its place with no preamble.
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?
No output schema exists, so the description correctly compensates by stating that a url is returned and where to use it. It omits any error/invalid-input behavior, which is the only gap for a 4-parameter write tool.
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?
Schema coverage is 100%, so baseline is 3, but the description adds the cross-parameter constraint 'exactly one of url or file_base64', which is genuine value beyond per-field docs. filename semantics are left to 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?
Specific verb (upload/загрузка) plus a narrowly scoped resource (image for the 'media choice' answer-option widget), which implicitly separates it from the sibling upload_quiz_media and upload_workspace_logo. An agent can tell what this produces without opening the schema.
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?
States the context clearly (answer-option images for the media-choice widget) and closes the loop by telling the agent to feed the returned url into choiceImageEntities[].link in update_quiz_widgets. No explicit 'when not to use' or named alternative to upload_quiz_media, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Загружает логотип рабочего пространства по ссылке или из base64. Логотип подставляется во все опросы, отчёты и PDF пространства. Укажите ровно один способ: url или file_base64.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Публичная http(s) ссылка на файл логотипа. | |
| filename | No | Имя файла — используется при загрузке из base64 (необязательно). | |
| file_base64 | No | Содержимое файла в base64 (допускается префикс data:...;base64,). | |
| workspace_id | Yes | ID рабочего пространства. Взять из workspace://list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the description only needs to add context - and it does, by disclosing the propagation effect: the logo is injected into all quizzes, reports, and PDFs of the workspace. It stops short of stating what happens to an existing logo (overwrite) or any size/format constraints.
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?
Three short sentences, front-loaded with the action, then the effect, then the input rule. No filler and each sentence carries distinct information.
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 mutation tool with no output schema, the description covers the action, the accepted input modes, and the visible effect across the workspace. It omits overwrite behavior, permission requirements, and accepted file formats/sizes, which would matter for correct invocation but are relatively minor.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it imposes an 'exactly one of url or file_base64' constraint that the schema itself does not express (both are optional with no oneOf). This resolves a real ambiguity about valid input combinations.
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 states a specific verb and resource ('Загружает логотип рабочего пространства') and clarifies the two accepted sources (URL or base64). It does not explicitly differentiate itself from near siblings like upload_quiz_media, upload_quiz_widget_image, or delete_workspace_logo, relying on the tool name to carry that distinction. Clear but without explicit sibling routing.
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?
It provides a mutual-exclusivity rule ('Укажите ровно один способ: url или file_base64'), which is a usage constraint, but gives no guidance on when to prefer this tool over alternatives or any prerequisites (permissions, allowed formats/limits). Usage is implied rather than explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Проверяет связь с подключённым хранилищем: пробует записать и прочитать пробный файл. Удачная проверка возвращает запись новых файлов в своё хранилище, если оно раньше отвалилось и запись временно шла на диск платформы. Запускать может только владелец аккаунта.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ID воркспейса (из workspace://list). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-read-only, non-idempotent operation, and the description explains the write/read test-file activity that justifies that profile plus its real side effect (re-routing new file writes back to the user's storage). It also discloses the owner-only auth requirement, adding value beyond 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?
Three tight sentences front-loaded with the action, then the effect, then the permission constraint. No wasted text, though it is slightly dense for a single-parameter tool.
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?
With no output schema, the description does explain the meaningful outcome of a successful check. For a one-parameter verification tool it is largely complete, missing only explicit return-value detail and sibling routing.
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?
There is a single parameter with 100% schema description coverage, including the workspace://list reference, so the schema carries the meaning. The description adds nothing about the parameter, which is the expected baseline when coverage is high.
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?
States a specific verb and resource: it checks the connection to the connected storage by writing and reading a test file. The action is clearly distinct from read-style siblings like get_workspace_storage or get_workspace_storage_usage, though the description never names those siblings to make the routing explicit.
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?
It gives useful context for when the check matters (recovering file writing after storage 'fell off') and states the restriction that only the account owner can run it. However, it never states when to prefer this over the sibling get_workspace_storage / get_workspace_storage_usage, leaving the choice implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_promocodesadd_quiz_email_recipientapply_quiz_themearchive_quizconfirm_quiz_email_recipientcreate_answer_tagcreate_booking_blockcreate_foldercreate_hidden_optioncreate_promocode_groupcreate_quizcreate_quiz_from_templatecreate_quiz_variablecreate_quiz_webhookcreate_report_appearance_presetcreate_themecreate_widget_hidden_optiondelete_answer_tagdelete_booking_blockdelete_favorite_questiondelete_hidden_optiondelete_quizdelete_quiz_answersdelete_quiz_email_recipientdelete_quiz_variabledelete_quiz_webhookdelete_report_appearance_presetdelete_schedulerdelete_widget_hidden_optiondelete_workspace_logodelete_workspace_roleduplicate_quizduplicate_schedulerexport_answers_csvexport_answers_spssexport_answers_wordexport_answers_xlsxexport_filtered_report_pdfexport_filtered_report_wordexport_quiz_printexport_summary_pdfgenerate_ai_quizgenerate_ai_reportgenerate_filtered_reportget_ai_reportget_answer_extra_field_valuesget_answer_tagsget_booking_journalget_favorite_questionsget_folder_listget_integration_logsget_mailing_stateget_partner_programget_promocode_codesget_promocode_listget_promocode_list_quizzesget_quiz_answersget_quiz_crm_fieldsget_quiz_email_settingsget_quiz_hidden_optionsget_quiz_integrationsget_quiz_listget_quiz_reportget_quiz_report_filesget_quiz_report_filtersget_quiz_report_inputsget_quiz_structureget_quiz_summaryget_quiz_textsget_quiz_variablesget_quiz_versionsget_quiz_webhook_logsget_quiz_webhooksget_quiz_widgets_hiddenget_respondent_campaignsget_schedulersget_tariff_listget_theme_detailsget_theme_listget_user_meget_workspace_detailsget_workspace_domain_statusget_workspace_hidden_filesget_workspace_listget_workspace_member_accessget_workspace_membersget_workspace_report_appearanceget_workspace_rolesget_workspace_storageget_workspace_storage_usageget_workspace_tariffget_workspace_templatesinvite_workspace_membermake_quiz_templatemanage_folder_accessmanage_partner_sourcemanage_promocode_groupmanage_quiz_amocrm_mappingmanage_quiz_analyticsmanage_quiz_crmmanage_quiz_crm_mappingmanage_quiz_google_sheetsmanage_quiz_messengermanage_quiz_passwordsmanage_quiz_paymentmanage_quiz_qr_codemanage_quiz_unique_linksmanage_quiz_zapiermanage_thememanage_user_sessionsmanage_workspace_domainmanage_workspace_filesmanage_workspace_foldermanage_workspace_smtpmove_quizpublish_quizremove_workspace_memberrename_quizresend_integration_logsresend_quiz_webhook_logresend_workspace_member_inviterestore_quizrestore_quiz_versionsave_favorite_questionsave_quiz_email_templatesave_quiz_report_filterssave_schedulersave_workspace_rolesearch_quiz_templatesset_answer_noteset_answers_order_modeset_quiz_email_questionsset_quiz_linkset_workspace_member_foldersset_workspace_member_roleshare_ai_reportshare_answers_linkshare_report_linkshare_summary_linktag_answertoggle_answer_visibilitytoggle_quiz_emailtoggle_quiz_email_recipienttoggle_quiz_webhookupdate_bookingupdate_hidden_optionupdate_quiz_logicupdate_quiz_noteupdate_quiz_settingsupdate_quiz_textsupdate_quiz_variableupdate_quiz_webhookupdate_quiz_widgetsupdate_themeupdate_user_profileupdate_widget_hidden_optionupdate_workspace_brandingupdate_workspace_report_paletteupload_quiz_mediaupload_quiz_widget_imageupload_workspace_logoverify_workspace_storage
Add one secure layer between your agents and this server.