Skip to main content
Glama
Sign In

24Repost

by io.github.24repost-ru
OverviewDiscussionsAdmin

chatbot_save

Сохраняет сценарий чат-бота: новый (черновик) или правку существующего. Сценарий передаётся целиком, по схеме поля scenario. Перед записью он проверяется для площадки бота; если в нём есть ошибки, он не сохраняется, а ошибки возвращаются словами с номерами шагов. Сохранение не включает сценарий: включает chatbot.enable. Правка уже включённого сценария действует сразу.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "botId": "<botId>",
      "scenario": "<scenario>"
    },
    "name": "chatbot_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
botIdYesНомер своего бота клиента (uuid) — из ответа действия chatbots.list без указания бота.
revisionNoРевизия сценария, на которой правили (поле revision из chatbot.show). Если за это время сценарий успели изменить, сохранение отклоняется. Для нового сценария не указывается.
scenarioYesСценарий чат-бота для личных сообщений. Человек начинает с первого шага, каждый шаг называет следующий по номеру (поля next, else) или заканчивает разговор. Ответ на вопрос ждёт шаг question, срок — wait, кнопки есть у шага message, ветвление — шаг condition
scenarioIdNoНомер сценария, который правят. Не указан — заводится новый черновик.
secretValuesNoТолько для окна «Переменные» в кабинете: новые значения скрытых констант, имя → значение. Нейросети, сервер MCP и ключ API значения не задают и не видят — передавать это поле им нельзя.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=false) it discloses what actually happens on the write path: platform-specific validation before persisting, all-or-nothing behavior (a scenario with errors is not saved), error output as human-readable text with step numbers, and that edits to an already enabled scenario take effect immediately. That last point is a real consequence an agent cannot infer from 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.

Conciseness5/5

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

Five short sentences, no filler, with the core action and the new-vs-edit split front-loaded. Each subsequent sentence carries a distinct operational fact (full payload, validation, enabling, immediate effect), so nothing could be deleted without losing information.

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

Completeness4/5

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

For a heavy nested tool with no output schema, the description covers the failure mode (rejected save with step-numbered errors) and the follow-up action (enable via chatbot.enable). The remaining gap is what a successful save returns — e.g., the new scenario id or revision to reuse — which an agent needs for chaining.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description nevertheless adds a fact the schema does not state plainly: the scenario must be supplied whole rather than as a diff, which directly shapes how the `scenario` parameter must be populated. It says nothing extra about `revision`, `scenarioId`, or `secretValues`, which the schema already covers well.

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

Purpose5/5

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

The first sentence names a specific verb and resource (saves a chatbot scenario) and splits the two modes — new draft vs. edit of an existing one. It also separates itself from chatbot.enable ('Сохранение не включает сценарий: включает chatbot.enable'), which sits in the sibling list, so an agent can route 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.

Usage Guidelines4/5

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

It states the two legitimate contexts (new draft, or editing an existing one), the precondition that the scenario is passed in full ('Сценарий передаётся целиком'), and where enabling lives instead. It stops short of telling the agent to call chatbot_show first for the current revision, leaving that hint to the parameter 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.

All 24Repost toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources