operbots-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.14
Disambiguation5/5
Every tool has a clear, distinct purpose tied to a specific resource and action. Even within the same resource, tools like flows_save, flows_publish, and flows_simulate are clearly differentiated.
Naming Consistency4/5
Most tools follow a consistent resource_verb pattern (cases_list, flows_get, dialogs_reply). Minor deviations include the operbots_ prefix for a few server-level tools and the standalone whoami, but these are relatively isolated and do not cause confusion.
Tool Count2/5
With 55 tools, the server is on the heavy side. While the breadth may be justified by the complexity of the platform, it exceeds the typical range and risks overwhelming the agent.
Completeness4/5
The toolset covers CRUD operations for most resources, including cases, bots, flows, dialogs, knowledge bases, and AI services. Notable gaps include the lack of explicit task creation/update tools and the inability to update knowledge documents without duplicating them.
Average 4.3/5 across 55 of 55 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results include comments and dates, giving some return-content context, but no details on pagination 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the main content, no redundant words. It could benefit from a verb, but structure is efficient.
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 simple read-only list tool with no output schema, the description provides the essential return content (all revisions with comments and dates) and annotations cover safety. However, it doesn't explain ordering, pagination, or the exact structure of each revision, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented. The description adds no parameter-specific context beyond what the schema provides; baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (saved revisions of a script) and implies a listing operation, but lacks an explicit verb. It doesn't distinguish from sibling tools like flows_list or flows_get, though 'редакции' clarifies it's about version history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as flows_get or flows_restore. The description only states what is returned, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond that, including the meaning of counters and a clear explanation of each broadcast status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loads the core content. The status list is useful, though the informal aside about users who 'closed the bot's mouth' adds little functional clarity.
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?
Without an output schema, the description does a good job of explaining what the returned records contain and what each status means. It could be more explicit about the list nature and sorting, but it is adequate for a simple read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with case, limit, and offset already documented. The description does not need to explain parameters, and it adds no additional parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (case mailings) and the data they contain — selection conditions, text, and delivery counters — and explains the statuses. However, it never uses an explicit action verb like 'list' or 'get', relying on the tool name to supply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus broadcasts_preview, broadcasts_save, broadcasts_start, or broadcasts_cancel. It does not state that this is the read-only viewing tool or mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds meaningful context about the informational content returned (scenario position, expected answer, variables), going beyond what annotations alone provide. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a colon-led list. It is front-loaded with the core subject and each listed item adds useful detail. No filler or redundancy.
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 simple read-only getter with full schema coverage and no output schema, the description adequately explains what the agent will learn from the call. It outlines the key aspects of the dialog card without needing to specify return format. Minor lack of error/edge-case handling is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters ('case' and 'dialog') have clear descriptions in the schema. The tool description adds no extra parameter-level semantics, so it cannot exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the tool's focus: it provides the dialog and its position in the scenario, including current step, expected response, path, planned steps, and variables. This distinguishes it from sibling tools like dialogs_list or dialogs_history. However, it lacks an explicit verb like 'get' or 'retrieve', relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives (e.g., dialogs_list, dialogs_history, dialogs_reply). It does not mention exclusions, prerequisites, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it indicates unread messages and operator status, but does not disclose pagination behavior or return format, so it provides only limited extra context.
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?
The description is a single, two-sentence statement focused on the action and key capabilities. It is appropriately sized and front-loaded, with no unnecessary 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?
The combination of a clear description, thorough schema, and safety annotations provides sufficient context for a list operation. It could mention pagination defaults or return format, but these are not required given the schema details and read-only annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters with descriptions (100% coverage). The description's mention of filtering by bot, mode, and substring repeats the schema without adding additional semantic nuance, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists bot conversations filtered by bot, mode, and substring, and mentions it shows unread and operator-led dialogs. This distinguishes it from sibling dialog tools like dialogs_get or dialogs_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a listing tool but does not explicitly state when to use it vs alternatives or mention exclusions. It relies on the tool name and purpose to convey the use case, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior. The description adds useful context by specifying that the invitation link becomes unusable, which clarifies the exact impact of the operation beyond the generic destructive hint.
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?
The description is a single sentence with no filler, directly stating the purpose and effect. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool, the combination of annotations (destructiveHint) and fully described parameters makes the description sufficient. It clearly communicates the core action and outcome without requiring additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema. The tool description adds no extra parameter semantics, so the baseline score of 3 applies.
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 description clearly states the action with a specific verb 'Гасит' (revokes) and specifies the exact consequence: the invitation link will no longer work. This distinguishes it from related tools like invites_create and members_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or when to prefer alternatives. It simply describes the action without contextual cues about suitable scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable context by clarifying that access tokens are not listed and where to find them, which goes beyond what annotations provide. No contradictions found.
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?
The description is concise and front-loaded, with only two sentences that each add value. The first sentence introduces the purpose, and the second clarifies an exclusion, both essential for correct usage without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and the presence of clear annotations (readOnly, idempotent), the description fully covers what an agent needs to understand the tool's functionality and boundaries. It is complete for this simple case.
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?
The tool has zero parameters, and schema description coverage is 100%, meaning no parameter info is missing. The description adds no parameter meaning because there are none, but the baseline for 0-parameter tools is 4, as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool lists browsers/devices logged into the panel under the account, using a specific verb and resource. It differentiates from siblings by explicitly excluding access tokens, which helps distinguish it from tokens-related tools like bots_reveal_token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 logged-in devices) but does not explicitly state when not to use it or mention alternatives. It provides context about what is not included (access tokens), but lacks direction on when to use other tools for token management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context by disclosing that API keys are never shown—only their last characters—which is exactly the kind of safety-relevant detail that goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first sentence states purpose and scope; the second addresses key redaction. No wasted words, and every sentence earns its place.
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 simple list operation with one optional parameter and no output schema, the description provides sufficient information: what is listed, for what scope (case), and a critical privacy guarantee. It does not describe pagination or exact return format, but these are not necessary given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'case' parameter, including its default behavior when omitted. The description does not add further parameter-level detail, so with 100% schema coverage 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it lists AI services connected to a case, including models and bot usage counts. It distinguishes itself from sibling tools like ai_save, ai_test, and ai_delete by framing this as a read-only enumeration of existing connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('connected to the case') and the optional case parameter, but it does not explicitly state when to use this versus alternatives or provide exclusion criteria. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: secret variable values are hidden. This is a meaningful disclosure about response content that 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the core purpose with a colon list of contents; the second adds a crucial detail about secrets. No wasted words or redundant 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?
The description covers what the tool returns, including the masking of secret variables, which is important given there is no output schema. With strong annotations and 100% parameter schema coverage, it is nearly complete, though it does not explicitly address error cases or access restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'bot' and 'case' parameters have descriptive text. The tool description itself adds no extra parameter semantics, so the baseline score of 3 applies.
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 description clearly states the tool returns the full bot object ('Бот целиком') and enumerates its contents: settings, command menu, content variables, and scenario list. This distinguishes it from sibling tools like bots_list (list only) and bots_save (modify). The implicit verb is evident from the tool name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the comprehensive single-bot retrieval tool, but it does not explicitly state when to use it versus alternatives such as bots_list or bots_control. No exclusions or alternative tool names are mentioned, so usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds context about the output contents (status, operation mode, dialogue counts, unread), which is useful behavioral information beyond the annotations. No contradictions.
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?
The description is a single, compact sentence that front-loads the resource and purpose. It avoids unnecessary words while conveying the key output fields.
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 simple read-only list with one optional parameter, the description provides sufficient context: what is listed and what information is included. Annotations cover safety, and schema covers parameters. The lack of output schema is mitigated by the description's field enumeration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'case' is fully described in the schema (100% coverage), including default behavior when omitted. The tool description itself does not add parameter details, so it relies on the schema, appropriate for baseline 3.
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 description clearly identifies the tool as listing bots for a case ('Боты дела'), with a specific verb ('список') and resource ('боты'). It also lists the returned aspects (status, mode, dialog counts, unread), distinguishing it from sibling tools like bots_get by its list-focused scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving bots of a case, but it does not explicitly state when to use this tool versus alternatives (e.g., bots_get). No exclusions or conditions are mentioned, so it falls short of clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about what the returned case card contains, including current user rights in the case and the list of summary categories. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler words. It lists multiple summary categories, which is informative, but the long list makes it slightly heavy—still reasonably concise for the richness it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters, no output schema, and strong annotations, the description is sufficient for an agent to know what the tool returns: user permissions and a composite case summary. It also clarifies the date-bound correspondence aspect referenced by the 'days' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are already documented in the input schema: 'case' explains the matching and fallback behavior, and 'days' says 7/14/30 with a default of 7. The description does not need to add further parameter-level meaning.
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 description clearly defines the tool as a case card ('Карточка дела') that returns the current user's rights and a summary of bots, dialogs, correspondence, deferred actions, knowledge bases, and participants. This distinguishes it from cases_list, cases_save, and cases_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for viewing/opening a single case with details and rights, but it does not explicitly state when to use it instead of sibling tools like cases_list or bots_get. No when-not-to-use or alternative tool mention is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, open-world, idempotent, and non-destructive. The description adds value by specifying the access scope and response contents (role, rights, bot/unread counters), enriching behavioral understanding without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's purpose and scope. It contains no filler or redundant information relative to the annotations.
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 straightforward list tool with one optional parameter and rich annotations, the description is sufficient: it names the resource, access scope, and returned data fields. It does not describe pagination or the exact array format, but the absence of an output schema and the tool's simplicity make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (include_archived) is fully described in the schema with a default value, and the schema coverage is 100%. The description does not add parameter details, but the baseline of 3 is appropriate because the schema carries the semantic burden.
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 description states the tool lists all accessible cases ('Все дела, к которым есть доступ') and specifies the included data: role, rights, bot and unread counters. This clearly identifies it as the list operation for cases, distinguishing it from sibling tools like cases_get or cases_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool returns only cases the user has access to and includes an optional archived filter, but it does not explicitly state when to prefer this over cases_get or other list tools. Usage is implied rather than directly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, open-world, idempotent, and non-destructive. The description adds valuable context by specifying that the tool returns the entire graph along with diagnostics like 'connections to nowhere, missing trigger, unreachable nodes'. This goes beyond the safety profile provided by annotations and describes the tool's analytical behavior.
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?
The description is a single, concise phrase that immediately states the tool's scope and content. It contains no unnecessary words or repetition, making it efficient and well-structured.
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 relatively simple getter with no output schema, the description gives a solid overview of the returned data and even highlights diagnostic features. It does not cover error behavior or the optional 'case' parameter, but the schema and annotations cover most context, making it substantial enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for bot, case, and flow. The tool description itself does not add any parameter-specific semantics, so a baseline score of 3 is appropriate for high schema coverage.
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 title 'Открыть сценарий' (Open scenario) combined with the description 'Сценарий целиком...' clearly identifies this as a getter for a complete flow graph. It explicitly lists what is returned (all nodes, parameters, connections, graph remarks) and thereby distinguishes it from sibling tools like flows_list, which likely provides a list of flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving full scenario details but does not explicitly state when to use it versus alternatives such as flows_list or flows_versions. The phrase 'Сценарий целиком' suggests detailed inspection, but no exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: history is not rewritten and a new revision is layered on top, and the bot immediately behaves per the restored version if the scenario is live. Since annotations already cover safety, this extra context justifies a high score.
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?
The description is two concise sentences with no filler. The first sentence states the primary action, and the second adds key behavioral nuance, making it efficient and well-structured.
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?
With 100% schema coverage and annotations providing safety context, the description adequately rounds out the tool by explaining side effects. It lacks only an explicit return-value description, but this is minor for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description does not add any additional meaning to the parameters, aligning with the baseline of 3.
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 description clearly states the tool restores a scenario graph to a selected revision, using a specific verb and resource. It distinguishes itself from sibling tools like flows_save, flows_publish, and flows_versions by conveying the restore action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The behavior is described (new revision, immediate effect), but there is no explicit guidance on when to use this tool versus alternatives. Usage is implied by the purpose rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining the consequence: 'the bot will not send what it was going to.' The annotations already mark the operation as destructive, so the description contributes additional semantic detail about the effect, though it does not cover edge cases or permissions.
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?
The description is a single, front-loaded sentence that immediately states the verb 'Снимает' (removes). It is compact with no filler, every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description combined with the schema and annotations provides sufficient information for an agent to invoke it. It lacks information about error cases (e.g., task not found) but that is not critical for a basic cancellation tool. The description fully explains the core action and its effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself makes no mention of the parameters, but the input schema provides complete descriptions for both 'case' (default/fallback behavior) and 'task_id' (identifier from tasks_list). Since schema_coverage is 100%, the description is not required to compensate, so a baseline 3 is appropriate.
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 description clearly states that the tool 'removes a scheduled action: the bot will not send what it was going to' (Снимает запланированное действие). The title 'Cancel delayed action' aligns perfectly. This is distinct from tasks_list and other sibling tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, or conditions under which it should not be used. The usage is implied from the purpose, but no explicit context or exclusions are given. Therefore it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutability and non-destructiveness, so the bar is lower. The description adds valuable behavioral context by explaining that start performs command menu synchronization and that separate sync is needed after command edits—details not present in the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema) and the annotations available, the description covers the core actions and the important sync nuance. It is sufficiently complete for an agent to select and invoke the tool correctly.
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?
All three parameters are fully described in the schema (100% coverage), giving a baseline of 3. The description goes beyond by explaining the relationship between the action parameter and the sync behavior, particularly why sync_commands may be necessary after editing commands, which adds semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: launching, stopping, restarting a bot, and sending the command menu to Telegram. However, it does not explicitly differentiate from sibling tools like bots_commands_apply, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: starting the bot syncs the menu automatically, and a separate sync is needed after editing commands for an already running bot. It does not mention alternative tools or exclusions, but gives concrete scenarios for when to use this tool's sync_commands action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral detail beyond annotations by specifying that the response is ready-to-use JSON in the operbots.flow format and identical to the panel's download output.
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?
Two sentences with no redundancy: the first front-loads the core contract, the second explains how the result should be consumed. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only export with three well-documented parameters and no output schema, the description fully compensates by describing the response format and its intended downstream usage. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so the baseline is 3. The tool description does not add parameter-level detail, but none is needed given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a flow as a single operbots.flow object, matching the panel's Download button. It names the specific resource and output format, though it does not explicitly contrast itself with flows_get or other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the intended downstream use: pass the JSON to flows_import via the document field or save it as a copy near code. This gives practical context for when to use the tool, but it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructive intent. The description adds useful context beyond annotations by explaining that node configurations are documented in node_kinds, which helps the agent anticipate the content returned. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the purpose. It lists the catalog types efficiently and provides a specific usage recommendation. It is slightly dense but every sentence contributes value.
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?
The tool has only two parameters and no output schema. The description covers the tool's purpose, content, and provides a direct usage pointer (node_kinds). It does not detail return format or pagination, but the simplicity and annotations make the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (what and kind). The description adds a conceptual hint about node_kinds being the source for node configs, but does not elaborate on the syntax or additional semantics of the 'kind' parameter. The schema already provides the necessary details.
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 description clearly states the tool's role as a catalog/reference: it lists node kinds, flow templates, AI services, and permissions. It explicitly mentions the full set of node configuration settings, distinguishing it from action-oriented sibling tools like cases_delete or flows_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to consult node_kinds before assembling or editing a scenario, indicating a specific when-to-use. It does not mention alternatives or exclusions, but the catalogue nature is evident from the context and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable context: becoming the owner, the five roles expanded, and the archive action. This goes beyond the structured data without contradicting it.
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?
Two sentences, front-loaded with the primary create behavior, and every clause earns its place. It's concise yet covers both modes and the side effects (ownership, roles, archive) without waste.
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?
The tool has two modes and non-trivial side effects, but the description covers them adequately. There is no output schema, and the description doesn't mention return values, which would be helpful. However, the action is clear and the schema fills in parameter details, so it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter documented. The description doesn't add parameter-level detail beyond the schema, which is the baseline expectation. The schema already explains the 'case' parameter's omission behavior, so the description adds no extra semantic value.
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 description clearly states the tool creates or modifies a case, with an explicit verb for each mode ('создаёт новое' and 'меняет'). It distinguishes from sibling tools like cases_list, cases_get, and cases_delete by describing its dual create/update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditional usage: omit 'case' to create, specify it to update. It doesn't explicitly name alternatives, but the conditions are explicit and easy to follow. No exclusions are mentioned, but none are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by explaining exactly what happens to the previous owner (demoted to admin, loses re-transfer rights) and that only the new owner can transfer back. This provides critical behavioral detail not available elsewhere.
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?
The description is two sentences long, front-loaded with the core action, and every clause adds value. No filler or redundancy.
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 destructive, non-idempotent tool with no output schema, the description explains the transfer, the consequences for both parties, and the irreversible nature. It lacks explicit prerequisites (e.g., current owner must invoke) but is otherwise complete for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The tool description does not add additional parameter meanings beyond the schema, leaving confirm_name and member semantics to the schema.
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 description clearly states the action: making another participant the owner of a case. It distinguishes from related tools like cases_leave or cases_delete by specifying the transfer of ownership and its consequences, so 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios (when you need to change case ownership) but does not explicitly contrast with alternatives or state when not to use it. The context is clear enough for an agent to infer, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already indicating destructiveHint=true, the description adds significant context: it deletes the entire revision history, is irreversible ('Восстановить нельзя'), and describes the consequence of deleting a working scenario (bot remains without a canvas). This goes well beyond what annotations alone provide, making the destructive nature crystal clear.
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?
The description is three short sentences, each carrying necessary information: what is deleted, irreversibility, and impact on the bot. It is front-loaded with the core action and contains no redundant or filler content.
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 destructive tool with no output schema, the description explains the scope, irreversibility, and operational consequence. It does not explain the confirm_name parameter's purpose in text, but the schema already does that. Overall, the description is sufficient for an agent to understand the tool's behavior and risk, though it could mention confirming the exact name as a safety step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with clear descriptions, including the safety confirmation parameter (confirm_name). The description adds no extra parameter-level detail, which is acceptable since the schema is already complete. Baseline 3 applies.
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 description uses a specific verb ('Удаляет' / deletes) and names the exact resource ('сценарий' / scenario), clearly distinguishing it from sibling flows_* tools like flows_save or flows_restore. It also states the deletion includes the entire revision history, which makes the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for permanent deletion of a scenario, but it does not explicitly state when to use it over alternatives (e.g., flows_restore for version recovery). The warning about bot impact implies caution, but there is no 'use this only when...' or comparison to other flows tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=false, and the description adds meaningful context: the server does not send the link, and anyone with the link can join with the specified role. This goes beyond the annotations and helps the agent understand the tool's side effects and security implications.
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?
The description is two sentences long, front-loaded with the primary action, and every clause adds value. It avoids redundancy and is well-structured for quick comprehension.
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?
With 5 optional parameters and no output schema, the description should clarify the result. It implies the tool returns a link (since the server does not send it) but does not explicitly state the return format. It also omits any permission prerequisites, but overall it covers the essential behavior well for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value to parameter understanding—it mentions 'specified role' but does not elaborate on the case default, email restriction, max_uses, or TTL. The schema already provides clear per-parameter descriptions, so the description is not required to repeat them.
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 description clearly states the action: 'Делает ссылку для вступления в дело' (makes a link to join a case). It uses a specific verb and resource, and distinguishes from sibling tools like invites_revoke by focusing on creation. It also adds the important detail that it works for unregistered users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to generate an invitation link) and clarifies that the server does not send the link, so the user must distribute it. However, it does not explicitly mention when not to use it or name alternative tools, though this is a straightforward create operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety expectations. The description adds useful behavioral context: the material can be referenced by name ('Материал можно назвать по имени — идентификатор не обязателен') and that chunks=true reveals the chunking used for model ingestion. These insights go beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each delivering a distinct piece of information: the tool's purpose, a comparison to the list, and the optional chunks behavior. It is front-loaded with the core purpose and contains no filler or redundancy.
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 read-only retrieval tool with full parameter descriptions and safety annotations, the description is complete enough. It explains what the tool returns (the material's text), highlights the key usage context (list doesn't include text), and covers the optional chunks flag. It doesn't detail the return format or error handling, but given the simplicity and existing schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for all four parameters. The description reinforces the name-or-ID flexibility for the document parameter and explains the chunks option, but these details are already present in the schema. Thus, the description adds minimal new semantic value beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states the tool's core function: retrieving the full text of a material ('Материал с его текстом: что в нём написано на самом деле'). It also distinguishes itself from the material list, which does not include text, and mentions the optional chunks output. This is a specific verb+resource definition with clear differentiation from sibling tools like knowledge_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with the material list: 'Список материалов текста не отдаёт' (the list does not give the text), implying this tool should be used when the actual text is needed. It also explains when not to use chunks by default because they 'повторяют текст и удваивают ответ'. While it doesn't name all alternatives, it provides clear guidance for the primary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, open-world, idempotent operation. The description adds meaningful behavioral context beyond that: it specifies that without 'base' it returns all knowledge bases with settings, and with 'base' it also returns a material list with parsing status. This gives the agent insight into output richness and conditional behavior, though it does not cover edge cases like empty results 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core behavior and then expands on the conditional variant. Every word contributes to understanding the tool's output and parameter effect, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple optional-parameter structure, no output schema, and strong annotations, the description adequately explains what the tool returns under both invocation modes. It would benefit from mentioning return format details or pagination, but the provided information is sufficient for an agent to know what to expect in typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('base' and 'case'), so the schema already documents their meaning. The description adds conditional behavior tied to 'base', but this is more about output shape than parameter semantics. The 'case' fallback behavior is already documented in the schema, so the description does not significantly elevate parameter understanding.
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 description clearly indicates the tool lists knowledge bases ('все базы знаний дела с их настройками') and optionally their materials when 'base' is provided. It distinguishes itself from sibling tools by detailing the conditional output scope, making the purpose specific and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the behavior with and without the 'base' parameter, effectively telling the agent when to expect different result sets. It does not explicitly name alternative tools or exclusions, but the context is sufficient for choosing this tool over knowledge_search or knowledge_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a useful behavioral detail: sections lacking permissions are marked as unavailable. This goes beyond the annotations and helps the agent understand partial access scenarios.
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?
The description is extremely concise: two sentences, the first listing the three output categories (members, roles, invitations), the second adding a single limitation note. Every word earns its place, no redundancy.
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 simple two-parameter read tool with full annotations, the description is nearly complete. It covers the primary output categories and a key permission-related behavior. Minor omissions like pagination or exact return format are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (case, with_permissions) are fully documented in the schema. The description's phrase 'with what final rights' overlaps with the with_permissions parameter but does not add new semantic meaning beyond the schema.
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 description clearly identifies the tool as a read operation for case members, roles, and invitation links, enumerating the specific data returned. It distinguishes itself from mutation siblings like members_save, roles_delete, and invites_create by focusing on listing current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only query context via its listing content and the readOnly annotations. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The sibling set and annotations make the context clear, but the description alone lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the interactive flow: a window opens, a human enters the token, and the token never appears in correspondence. Annotations do not contradict this, and the added context about human involvement and token handling is valuable.
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?
The description is concise and front-loaded: the first sentence states exactly what the tool does, followed by essential token-handling and usage guidance. No fluff or unnecessary repetition.
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?
The description covers the purpose, triggering context, and a key security/behavioral detail about token privacy. With no output schema, it might have said what the tool returns on success/failure, but the entry flow is well clarified and enough for this auth setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (url and switch_account), with 100% coverage. The tool description doesn't add extra parameter-level detail, so the baseline score is appropriate.
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 description clearly states this tool opens a window for entering a panel URL and access token. It distinguishes itself from siblings (e.g., operbots_logout, bots_reveal_token) by focusing specifically on initial auth setup and re-authentication when access is missing/expired.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to invoke the tool: when other tools report that access is not configured or the token is no longer valid. It does not contrast it with all alternatives, but this is sufficient guidance for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=false and destructiveHint=false, and the description adds useful behavioral context: mutation of existing roles is possible, preset roles are protected from editing, and copy_of enables duplication before customization. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with the core action and then the key exception. No wasted words; every sentence adds useful guidance.
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 create/update tool with 8 optional parameters, the description covers the core behavior and the main non-obvious rule (immutable presets). Given the rich schema, this is sufficient for an agent to call the tool correctly, though a bit more about replacement semantics could have been included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries the per-parameter meaning. The description adds context around copy_of and presets, but most parameter semantics are already well documented in the schema, so no major compensation is needed.
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 description states a specific action ('заводит роль' / 'меняет существующую') on a clear resource (роль в деле), and it distinguishes itself from roles_delete by covering create/update semantics. The title and description align, and the mention of custom roles vs presets adds precision.
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 provides explicit conditional guidance: ready-made roles cannot be edited, and copy_of is the path to customize a preset. It does not explicitly name sibling roles_delete as the deletion alternative, but for create/update usage the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description adds valuable behavioral details: read actions are never recorded, actions performed by an access token are attributed to that specific token, and audit.view permission is required. These traits are not inferable from the annotations or schema alone.
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?
The description is compact, front-loaded with the core purpose, and every sentence adds meaningful information: content scope, the 'who did it' angle, token attribution, read exclusion, and permission requirement. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 four optional parameters and no nested objects, the description covers the essential behavioral context: what is logged, what is not logged, token attribution, and permission needs. The schema handles parameter semantics, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the schema already documents case, limit, action, and offset. The description does not add any parameter-specific meaning beyond the general 'case' context, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists an audit/action log for a case, covering edits, additions, deletions, and permission grants, and answers 'who did it.' This is specific and the scope is evident, though it does not explicitly contrast itself with sibling tools like bots_journal or dialogs_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use the tool: to determine who performed changes in a case. It also provides a useful exclusion—read operations are not logged—and warns about the required audit.view permission. However, it does not name alternative tools or explicitly state when not to use this tool in favor of another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: sent messages cannot be recalled, a canceled broadcast cannot be resumed, only a draft can be started again, and counters remain to show delivery reach. This gives the agent a clear picture of irreversibility and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver the core action and all critical consequences without redundancy. The most important fact is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with no output schema, the description covers what happens to unsent and sent messages, whether the operation is resumable, how to repeat the broadcast, and what remains visible. Combined with the annotated safety profile and fully documented schema, this is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents the 'case' and 'broadcast' parameters. The description adds no parameter-level detail beyond the schema, 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.
Purpose5/5
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 ('Останавливает рассылку') and immediately clarifies the effect: unsent messages will not be sent. This clearly distinguishes the tool from siblings like broadcasts_start, broadcasts_list, and broadcasts_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a broadcast needs to be stopped before it finishes sending. However, it does not explicitly name alternatives or state when not to use it, so the guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior beyond those: replies are ordered by insertion frequency with the most frequently used at the top, and it explains the relationship to dialogs_reply. No contradiction with annotations.
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?
Three short sentences accomplish purpose, ordering behavior, and cross-tool routing with no filler. The most important information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 one optional, fully documented parameter and no output schema, the description is complete: it states what the list contains, how it is ordered, and how to send a listed reply elsewhere. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the optional 'case' parameter, including default behavior when it is omitted. The description itself does not add further parameter detail, so with 100% schema description coverage 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies replies_list as listing operator canned responses ('Заготовленные ответы оператора') with concrete examples. It is easily distinguished from siblings like replies_save, replies_delete, and dialogs_reply by naming the action and cross-referencing the send operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when to use this tool (to view pre-prepared operator replies) and even points to the alternative for sending a reply: dialogs_reply reply=«название». It does not explicitly state exclusion conditions versus replies_save/replies_delete, but the listing purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description adds valuable context that the device is kicked out of the panel and that access tokens remain unaffected, going beyond the annotation flags without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear front-loading: the action and source are stated first, followed by a critical behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, annotations covering destructive behavior, and an explicit note about token impact, the description fully covers the essential context. No output schema is needed for this simple revoke action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains the session_id source. The tool description merely repeats the same information, adding no new semantic detail beyond what the schema provides.
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 description clearly states the tool ends a session by ID from sessions_list, using specific verb 'Завершает' and resource 'сессию'. It distinguishes from siblings like sessions_list (which lists sessions) and account_update, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the prerequisite (get ID from sessions_list) and a key usage nuance (does not affect access tokens). However, it doesn't explicitly mention when NOT to use this tool or alternative termination methods, though the context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral details beyond the annotations: passed keys are appended onto existing ones, and an empty string cannot erase a key—only overwrite it. This gives the agent a concrete understanding of side effects for a non-idempotent, non-destructive mutation tool.
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?
The description is compact and well-structured: it opens with the core create/update rule, then moves to provider-specific key requirements, and closes with the merging caveat. Every sentence carries necessary information without redundancy.
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 complex tool with 12 parameters, a nested `credentials` object, and no output schema, the description adequately covers the trickiest aspects: the create/update distinction, per-provider credential requirements, and key-merge behavior. It does not explain return values, but this is a minor omission for a save operation.
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?
The schema already covers all 12 parameters (100% coverage), but the description adds essential semantics by explaining the `credentials` structure per provider, including required fields and the default `scope` for gigachat. This compensates for the schema's generic 'see description' note and adds value beyond schema descriptions.
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 description clearly states the tool's purpose: it creates a new AI service connection when `provider` is omitted and modifies an existing one when `provider` is specified. It also distinguishes itself from sibling tools like `ai_list`, `ai_test`, and `ai_delete` by focusing on save/configure operations.
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 provides explicit conditions for use: without `provider` to create, with `provider` to update. It also lists required credentials per provider, giving concrete guidance on what inputs are needed for each service type. However, it does not explicitly mention alternative tools for reading/testing/deleting, so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical traits: unlisted commands are kept by default, removal requires remove_missing=true, and the Telegram menu update only occurs when sync=true or after a bot restart. This provides significant insight into side effects beyond the basic annotations.
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?
The description is three sentences, front-loaded with the main action, and every sentence adds value. It packs essential details without redundancy, making it easy to parse.
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 mutation tool with no output schema and 5 parameters, the description covers the core behavior, edge cases (keep vs remove), and external effects (Telegram menu sync). It provides sufficient context for an agent to invoke the tool correctly, though return values are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage). The description reinforces the semantics of remove_missing and sync but does not add new parameter-level information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'приводит ... к' (brings to) with a clear resource 'меню команд бота' and details the exact operations: adds missing commands, updates existing ones, and reorders according to the list. This unambiguously distinguishes it from sibling tools like bots_save or bots_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear behavioral context, such as the default preservation of unlisted commands and the condition for updating the Telegram menu via sync. However, it does not explicitly name alternatives or exclusions relative to other tools, but the operation is self-contained and well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds that the old address 'stops working forever' (перестаёт работать навсегда), reinforcing irreversibility. It also reveals a new side effect: the running bot restarts (работающий бот перезапускается), which annotations don't cover. This gives valuable operational context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences in Russian, each with a distinct purpose: action, condition, and side effect. No filler words, and the main verb appears in the first sentence, front-loading the purpose.
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 destructive, non-idempotent tool with no output schema, the description covers the key aspects: what it does, when to use it, and permanent consequences. It lacks explicit permission requirements, but given the annotations and schema, it is thorough enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (bot and case) with 100% coverage, so the baseline is 3. The description doesn't add parameter-specific semantics, but the schema does the heavy lifting. No additional meaning is provided by the description.
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 description clearly states the tool 'issues a new secret webhook address' (Выдаёт боту новый секретный адрес вебхука) for the bot, indicating a rotation action. It distinguishes from sibling bot tools (bots_get, bots_save, bots_delete) by focusing specifically on address rotation. The title 'Сменить адрес вебхука' aligns perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is needed 'if the old address leaked' (если старый адрес утёк), giving a clear trigger for use. It warns that the previous address stops working forever, implying it is not for routine changes. It doesn't name alternatives but provides sufficient context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds a valuable behavioral constraint: the owner cannot leave and must transfer the case first. This goes beyond the annotation flags and provides real context about preconditions and limitations.
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?
Two concise sentences, front-loaded with the primary action followed by the exception and alternative. Every word earns its place; there is no redundancy or unnecessary elaboration.
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 simple action with one parameter and no output schema, the description covers the core action, the key restriction, and the alternative. It does not mention edge cases like non-participant behavior, but given the annotations and simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'case' with a clear description ('Дело: название или идентификатор'). The tool description does not add further detail about the parameter, so baseline 3 is appropriate.
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 description clearly states the tool's function: 'Убирает вас из числа участников дела' (removes you from case participants). It specifies the action (remove) and the resource (your membership in the case), distinguishing it from sibling tools like case_transfer, which transfers ownership, and members_remove, which likely removes other members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool cannot be used ('Владелец выйти не может') and provides a clear alternative: 'сначала нужно передать дело другому участнику (case_transfer)'. This gives the agent actionable guidance on when to use this tool versus the case_transfer sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond those hints: the dialog is not marked as read ('Прочитанной переписка от этого не становится') and the export is recorded in the case journal ('сама выгрузка отмечается в журнале дела'). This is useful and does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, each carrying distinct information about output format, use cases, and side effects plus the alternative tool. It is slightly embellished with the phrase 'ровно то, что панель отдаёт файлом', but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description sufficiently explains the return format, the purpose, the side effects, and the sibling alternative. The input schema covers parameter details, so nothing critical is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (dialog and case) are already documented with clear descriptions and default behavior for case. The description does not add parameter-specific semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the whole conversation as one ready-made text with a header and messages in order, which is a specific verb+resource. It also distinguishes itself from dialogs_history, which is the sibling most likely to be confused with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the export is suitable for attaching to dispute analysis or sharing with someone without panel access. It also names dialogs_history as the better tool for per-message analysis and deep history, giving a concrete when-to-use vs alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds a valuable behavioral nuance: by default, it does not mark messages as read, leaving counters unchanged. This goes beyond the annotations and helps the agent understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence adds meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema), the description covers ordering, pagination, and read behavior, which are the critical aspects. It does not describe return fields, but that is not strictly necessary for this list-like tool. Slightly more detail on response structure could make it a 5.
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 enhances this by explaining how to use the 'before' parameter for deep history pagination and reiterating the default for mark_read. This adds practical value beyond the raw schema.
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 description clearly states that this tool returns dialog messages in chronological order from old to new, which is a specific action. It also mentions the default behavior of not marking messages as read, distinguishing it from other dialog-related tools like dialogs_reply or dialogs_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including how to paginate deeper into history using the 'before' parameter. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the non-obvious side effect that switching to bot mode returns the conversation to the scenario and removes the operator, and it explicitly warns that blocking is not possible via this tool. This is valuable behavioral context not encoded in the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: the first lists what the tool changes, the second explains the important side effect of bot mode, and the third states a limitation. No filler or redundant restatement of the title.
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 settings-update tool, this covers the essential behavior, side effects, and a key limitation. There is no output schema, and the description does not mention what the API returns or potential failure conditions, but the schema fully documents inputs and annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a small amount of meaning for mode (bot mode removes the operator), but the other parameters (dialog, case, tags, pinned, ai_enabled) are not elaborated beyond what the schema provides.
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 description names a specific verb ('Меняет') and the resource (dialog), and enumerates the mutated aspects: mode, AI answering, tags, and pinning. This clearly distinguishes it from sibling dialog tools like dialogs_list, dialogs_reply, and dialogs_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear from the stated purpose: update dialog settings. It also gives an explicit exclusion—blocking a contact cannot be done here and happens through Telegram. It does not, however, name sibling alternatives or provide broader when-to-choose guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint true, destructiveHint false), the description reveals that existing flows are left untouched, unresolved AI service and knowledge base links are removed, and each removal is reported in the response. This adds substantial behavioral detail not present in the structured annotations.
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?
Three concise sentences, front-loaded with the main action, no redundant wording. Every sentence adds value and structure is clear.
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 creation tool with a complex nested document parameter and no output schema, the description explains conflict resolution behavior and response content for link removals. It hints at the response but could be more explicit about the success return value, yet given the available annotations it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have schema descriptions (100% coverage), and the description only adds context (e.g., the document is the whole export from flows_export) without giving deeper parameter-specific meaning. This aligns with the baseline 3 for high schema coverage.
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 description clearly states it creates a scenario from an export object obtained via flows_export ('Заводит сценарий из объекта, полученного через flows_export'). This distinguishes it from related tools like flows_save or flows_delete by focusing on the import-from-export use case.
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 implies usage after flows_export and clarifies that existing flows are not overwritten and name conflicts get numbering, providing useful context. However, it does not explicitly contrast with flows_save for editing or specify when not to use this tool, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations indicating non-readonly, open world, non-idempotent, and non-destructive, the description adds crucial behavioral context: publishing disables all other flows, validation prevents publishing if there are links to non-existent nodes, and disabling leaves the bot without a canvas and unresponsive. These are significant consequences not disclosed in annotations alone.
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?
The description is two sentences, front-loaded with the main verb and resource, and every sentence carries important information: enable/disable action, exclusivity, validation check, and disabling consequence. No wasted words.
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?
The tool has no output schema, but the description sufficiently covers the main behavior and side effects. It lacks details like return values (success/failure messages) or whether active defaults to true, but the schema already indicates 'active' default. Given the tool's moderate complexity, the description is complete enough, though a note about success/failure output would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all four parameters have descriptions). The description adds context about validation and exclusive activation but doesn't add parameter-specific meaning beyond the schema. Baseline 3 is appropriate given full schema coverage.
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 description clearly states the tool's function: enabling/disabling a flow script, with the specific constraint that only one flow can be active at a time and turning off leaves the bot non-responsive. This distinguishes it from sibling flow tools (e.g., flows_save, flows_delete) and other bot controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is used (publishing/enabling a flow) and a critical consequence of disabling (bot stops responding). It doesn't explicitly name alternatives, but the title and context make it clear this is for activation/deactivation, not editing or deleting. The 'only one active' rule is a strong usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses that processing is asynchronous (material starts in pending), and that repeated calls create duplicates. This adds meaningful behavioral context useful for the agent.
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?
Three concise sentences, front-loaded with the primary action, followed by two important behavioral notes. No wasted words.
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 tool with no output schema, the description covers the key operational aspects: purpose, asynchronous behavior, duplicate prevention, and how to verify the result. It could mention edge cases like providing both text and URL, but overall it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description's general statement about text or URL adds minimal new meaning; the per-parameter details are already in the schema.
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 description clearly states it adds text or a URL page to the knowledge base ("Кладёт в базу текст или страницу по ссылке"), using a specific verb and resource. It also implicitly distinguishes from update tools by emphasizing that repeated calls create duplicates, not updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: background parsing, pending state, and a suggestion to check via knowledge_list. It warns against using repeated calls for updating, though it doesn't explicitly name an alternative for updates (e.g., knowledge_save).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool only queues materials for re-parsing ('ставит в очередь') and reveals a significant default behavior: 'Без параметра document пересобирается вся база' (without document, the entire base is rebuilt). This complements the annotations, which already mark the operation as non-read-only and non-idempotent; no contradiction exists.
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?
The description is only two sentences long and front-loaded with the core action. The first sentence states what the tool does, and the second provides usage context and the document-omission default — every sentence earns its place.
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 3-parameter tool with no output schema, the description covers purpose, motivation, and default scope well. It does not explain the detailed effects on existing fragments or the final result of the reindex, but the queue semantics and full schema coverage make it sufficiently complete.
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?
The input schema already covers all three parameters at 100%, providing a baseline of 3. The description adds valuable semantic context by specifying that omitting 'document' triggers a whole-base reindex, which is not stated in the schema itself.
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 description opens with a specific verb and resource: 'Ставит материалы в очередь на повторный разбор' (puts materials in queue for re-parsing). This clearly identifies the tool's purpose and differentiates it from sibling knowledge tools, which list, save, search, or delete materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: 'Нужно после смены размера куска или подключения к ИИ-сервису' (needed after changing chunk size or connecting to an AI service), and explains why old fragments remain stale. It does not name alternatives or explicitly state when not to use the tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true, so the mutation nature is declared. The description adds meaningful behavioral constraints not captured in the machine-readable annotations: created vs updated behavior depending on `base`, the empty-base restriction for changing/removing provider because vectors from different models are incompatible, and the need to rebuild chunks after changing chunk size via knowledge_reindex. No contradiction between description and annotations.
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?
The description is compact: three sentences, each carrying important operational information. It front-loads the primary create/update distinction, then adds the critical constraints. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 100% schema coverage, an output schema absent, and annotation hints present, the description is reasonably complete. It tells the agent the key conditional behavior, the vector-service requirement, the empty-base restriction, and the reindex follow-up. A minor gap: it doesn't explain what happens regarding the `active` flag or defaults, but those are covered by the schema. The open-world hint and no required parameters align with the flexible create-or-update nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover 100% of parameters, so the baseline is 3. The description adds value by explaining the crucial conditional behavior of `base` (omit to create, specify to update), which is not fully captured by the parameter description alone, and by relating `provider` to the vector-service requirement and `chunk_size` to the reindex action. However, it doesn't describe each parameter individually; the schema does that.
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 description clearly states a specific action: with no `base` parameter it creates a knowledge base, with `base` it modifies its settings. This distinguishes it from sibling knowledge tools like knowledge_list, knowledge_reindex, knowledge_search, knowledge_delete, and knowledge_add_document. The verb is explicit ('создаёт', 'меняет') and the resource (base of knowledge) is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use it without `base` (create) versus with `base` (configure), and it references the sibling `knowledge_reindex` for the case when chunk_size is changed. It also gives conditions: provider can be changed or removed only on an empty base, and the AI-vector-service connection requirement for search. This is clear enough for an agent to select this tool and avoid mistakes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, open-world, idempotent, and non-destructive annotations, the description adds a crucial behavioral nuance: if the base is disabled or vectors are not computed, the response will be empty without an error. This prevents misinterpretation of empty results and significantly enhances transparency.
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?
The description is two sentences, with the first sentence front-loading the core purpose and the second adding both the use case and an important edge-case behavior. Every sentence earns its place with no redundancy.
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?
The description is complete enough for a search/debug tool: it explains what is returned, how it is used, and a key failure mode. It does not detail the output structure (e.g., whether fragments include scores or metadata), but given the simple purpose and rich schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all four parameters, including defaults and constraints. The tool description adds no parameter-level details beyond what is in the schema, so the baseline score of 3 applies.
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 description uses a specific verb ('Показывает' = shows) and identifies the resource (which fragments the knowledge base will provide to the model for a given question). This clearly distinguishes it from sibling tools like knowledge_list, knowledge_save, or knowledge_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to verify that materials are parsed and the similarity threshold is correctly chosen. It does not mention alternatives or exclusions, but the intended use case is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by detailing the exact consequences: the removed person loses access to all bots, scenarios, and case correspondence. It also discloses the owner limitation, which is important behavioral information not present in annotations.
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?
The description is only two sentences, with the primary action stated first and the consequences/constraints in the second. It is concise, well-structured, and every sentence adds value.
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?
The description fully explains the purpose, consequences, and a key restriction. Given the simple tool with only two parameters and no output schema, it provides sufficient context for selection and invocation. It omits error handling details, but those are not essential for a user deciding to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (case and member), and the tool description does not add any additional parameter-specific details. With 100% schema coverage, a baseline score of 3 is appropriate.
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 description clearly states the tool's action: removing a person from a case. It uses a specific verb ('убирает') and resource ('человека из дела'), and the context about losing access distinguishes it from other member-related tools like members_list or members_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use the tool (to revoke a person's access to a case) and includes a critical restriction (the owner cannot be excluded). However, it does not explicitly mention alternatives like members_save, so it lacks direct when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating but non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: the presence or absence of member selects add-vs-update, and unregistered users are outside this tool's scope. It does not list all side effects, but the schema covers permission-list replacement, so the added context is sufficient.
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?
The description is compact: three short sentences, with the core mode distinction first and the relevant alternative routed at the end. Every sentence earns its place and there is no filler or repetition of the title.
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 two-mode mutation tool with 7 parameters and no required fields, the description resolves the main ambiguity (add vs modify vs invite) clearly. The exhaustive schema fills in parameter-level details. A minor gap is that it does not explicitly state which parameters become required in each mode or describe the return value, but an agent can infer this from the description plus schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: every parameter has a meaningful Russian description, so the baseline is 3. The tool description reinforces the member/email mode split and the role-override behavior, but it does not add much beyond what the schema already states for each parameter.
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 description names a specific operation with two clear modes: adding a registered user by email when member is absent, and changing a member's role and granular permissions when member is present. It also distinguishes itself from invites_create, which is for unregistered people. This makes its purpose unmistakable relative to siblings like members_list and members_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (add an already-registered person or modify their rights) and when not to use it (unregistered person: create an invite via invites_create). This direct routing to the alternative is exactly what an agent needs to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation via readOnlyHint=false, and the description adds behavior beyond that: reply toggles between creation and editing, and title is optional but affects whether the template has a name and can be invoked. No contradiction with annotations.
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?
Two compact sentences, with the main behavioral branch front-loaded and no filler. The second sentence adds a meaningful nuance about title without unnecessary detail.
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 save tool with 4 optional parameters and no output schema, it covers the key create/edit distinction and the practical consequence of omitting title. It does not describe return values or failure modes, but schema coverage and annotations carry enough of that burden.
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 schema documents all four parameters. The description adds meaning beyond the schema by explaining that reply switches between new and existing templates and that title is needed for invoking the template later, which is useful semantic context.
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 description states a specific action and resource: without reply it creates a new template ('заводит новую заготовку'), with reply it edits an existing one ('правит существующую'). This clearly distinguishes the tool's behavior from list/delete siblings and explains its core create-or-update semantics.
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 provides clear context for when to use each mode: omit reply for a new template, include reply to edit an existing one. However, it does not explicitly route to alternatives such as replies_list or replies_delete, so it stops short of full when-to-use vs alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=false), the description discloses that this is a real request consuming limits and potentially costing money. It also mentions it shows 'reason for refusal,' indicating potential failures. These are valuable behavioral traits not captured in annotations.
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?
The description is two sentences long, front-loaded with the action and outcome, and the cost warning is a necessary caveat. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no nested objects, no output schema) and the strong annotations, the description covers the essential aspects: what it does, what it returns (response or error reason), and the cost/limit implications. It is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (case, prompt, provider) already has a description. The tool description adds no additional parameter-level semantics, so it reaches the baseline but does not elevate it. It does not repeat or contradict schema information.
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 description states a specific verb+resource: 'Sends a test replica and shows the model's response or reason for refusal.' This clearly distinguishes it from sibling tools like ai_list or ai_save, as it is about testing an AI service rather than managing configurations or listing services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it sends a real request to the service and warns that it consumes limits and may cost money. This implies caution and informs when to use (testing a service) but does not explicitly name alternatives or exclusions. The cost warning is a useful usage guideline, though it could be more explicit about comparing to ai_list/ai_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and idempotent. The description adds meaningful behavioral context beyond annotations: it explicitly says no token or secret key is exposed, the address is shown without the key, and the output directly indicates whether the address matches what the panel expects. This is valuable safety-relevant context.
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?
The description is three sentences with no wasted words: the first sentence states what the tool returns, the second gives the diagnostic use case, and the third addresses security and output interpretation. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 compensates by clearly summarizing the retourned information: webhook URL, pending update count, last delivery error, and a match/mismatch signal against the panel's expected address. Combined with the read-only and idempotency annotations, nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, so the description does not need to add parameter-level detail. The tool description adds no extra parameter semantics beyond what the schema provides, which matches the baseline of 3.
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 description opens with 'Отчёт самого Telegram' and enumerates the concrete outputs: target address for updates, number of updates waiting for delivery, and last delivery error. This clearly identifies a specific diagnostic check on the webhook resource and distinguishes it from sibling tools like bots_webhook_rotate or bots_journal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger scenario: use this when a bot in webhook mode is silent even though the panel side looks healthy, and frames it as the only way to get Telegram's own explanation. However, it does not name alternative tools or state when not to use it, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, adding rich behavioral context: the symptom the user sees (a silent bot), the side-effect of canceling deferred continuations with the rationale ('would fire into the void'), and the post-condition (next message restarts the scenario). This adds genuine value beyond the generic readOnlyHint/idempotentHint flags. No contradiction found — canceling scheduled continuations is inherent reset semantics, not destruction.
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?
Two sentences, zero waste. The first sentence leads with the action and purpose, the second covers side effects and post-conditions. The vivid 'mute bot' and 'fire into the void' metaphors pack meaning into few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with only two string parameters, no output schema, and no nested objects, the description is complete: it covers the trigger condition, the side effect, and the resulting behavior. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (case, dialog) are already well-documented in the schema with their formats and defaults. The description adds nothing about parameters, which is acceptable per the baseline of 3 given full schema coverage, but there is no extra value either.
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 description uses a specific verb ('Освобождает' - frees/releases) and a specific resource (a conversation stuck at a wait node), clearly distinguishing it from sibling dialog tools like dialogs_list, dialogs_reply, or dialogs_delete. The real-world framing ('looks like a silently mute bot') makes the exact scenario unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear, specific context for when to use the tool: when a conversation is stuck at a wait node awaiting an answer that will never come. However, it does not name explicit alternatives or exclusions (e.g., 'use dialogs_delete if...'), so it falls just short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral details beyond annotations: it returns a list of flows with their operational status and node counts, plus the default fallback to all bots in the case when 'bot' is omitted. No contradictions; annotations and description align well.
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?
Two concise sentences. The first states what the tool returns, the second clarifies the default scoping. Every word adds value, and it's immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with rich annotations and full schema descriptions, the description covers the essential usage context. It communicates return highlights and default behavior without over-explaining, which is complete for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the 'bot' parameter's default behavior ('Без него — все боты дела'). The tool description reiterates this but adds no meaningful new parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
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 description clearly states the tool lists flows with specific contextual details ('какой из них в работе' for status, 'сколько в них узлов' for node counts). It also explains the default scoping behavior without the 'bot' parameter, effectively distinguishing it from single-flow retrieval tools like flows_get. This is a specific verb+resource+scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it by explaining the behavior with and without the 'bot' parameter. It implicitly differentiates from flows_get/flows_export and others, though it doesn't explicitly name alternatives or exclusions. This meets the 'clear context, no exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds concrete behavioral details: deleting a base removes all its materials and vectors, and restoration is impossible. This gives the agent a clear and complete picture of the destructive consequences before invocation.
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?
The description is two short sentences: the first front-loads the core operation and conditional behavior, and the second delivers the critical irreversibility warning. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the fully documented schema and the absence of an output schema, the description supplies the essential behavioral context: destructive scope, conditional operation, and irreversibility. No critical gaps remain for an agent to invoke this tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with descriptions, including the fact that omitting 'document' deletes the whole base. The description essentially restates this conditional behavior rather than adding new parameter-level meaning. Therefore, the high schema coverage keeps this at the baseline of 3.
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 description uses a specific verb ('удаляет') and clearly distinguishes the two deletion modes: one material when 'document' is provided, or the entire knowledge base with all materials and vectors when it is not. This makes the tool's purpose and scope immediately understandable and distinct from sibling knowledge tools.
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 gives explicit conditional usage guidance: include 'document' to delete a single material, omit it to delete the whole base. It also warns that deletion is irreversible, helping the agent weigh caution. It does not explicitly name alternatives, but no direct deletion alternative exists among the siblings, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as destructive and non-read-only, and the description adds the crucial behavioral nuance: only the template is removed, while previously sent messages remain unaffected. This is exactly the kind of contextual detail an agent needs 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundancy. The primary effect is stated first, followed by an important clarifying side-effect boundary. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with a required reply parameter and an optional case parameter, the description plus schema fully covers what the tool does, what is affected, and what remains. No output schema is needed for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with full descriptions, so the description does not need to repeat them. It adds no hidden semantics beyond the schema, which is acceptable given the 100% schema description coverage.
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 description uses a specific verb ('Убирает') with a clear resource ('заготовку из списка') and adds a scoping detail: sent messages remain, only the template itself disappears. This clearly distinguishes it from other delete-like siblings such as cases_delete or dialogs_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: it removes a reply template without deleting the messages sent using it. It does not explicitly name alternatives or exclusion conditions, but the context and sibling naming make the appropriate selection evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with destructiveHint=true, the description adds critical behavioral context: pre-made roles cannot be deleted, and roles with participants must be emptied first. This goes beyond the annotation to disclose failure conditions and required preconditions.
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?
The description is just two sentences: the first states the action, the second lists restrictions and a prerequisite. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two well-documented parameters, no output schema, and existing annotations, this description is complete. It covers purpose, restrictions, and a necessary precondition, giving the agent everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters (case and role). The tool description does not add any parameter-specific semantics beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Удаляет роль дела' (Deletes a case role). It uses a specific verb and resource, and is distinct from sibling tools like roles_save and cases_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for when the tool cannot be used (pre-made roles and roles with participants) and instructs a prerequisite action ('first move people to another role'). However, it does not explicitly name alternative tools, so it falls just 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds substantial behavior beyond them: completed tasks are retained and shown, ordering is by earliest deadline, no status means the response is dominated by old history, the panel performs filtering rather than the request, outputs cap at 300 records, and the total count is not disclosed. This is exactly the kind of context that prevents mis-calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph where every sentence earns its place: examples, retention behavior, ordering, filter advice, and response cap. It is not bullet-structured and slightly overlaps the schema's limit maximum, but nothing is padded and the most important caveat (no status → old history) is front-loaded.
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 simple optional-parameter list tool with annotations covering the safety profile, the description explains the key call-shaping behaviors: ordering, inclusion of done/cancelled records, the 300-record ceiling, and the lack of total-count reporting. The only gap is that no output schema exists and the description does not sketch the record fields returned per task, so an agent cannot fully predict response shape.
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 adds value by explaining the consequence of omitting status (you get old history) and by tying the 300-record cap to the limit parameter semantics, which helps the agent reason about pagination. It reinforces but does not duplicate the schema.
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 description opens with concrete examples of what is listed — «написать через три дня», «напомнить, если не ответил» — and states the resource (scheduled tasks in a case). The verb «Показывает» plus the scope makes it clearly a read-only listing tool, and its domain is distinguishable from the only same-domain sibling, tasks_cancel, by being a list rather than a mutation.
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?
Gives explicit in-tool guidance: ask for upcoming items with status=pending because the panel filters, and warns that omitting status returns stale history. It does not explicitly name alternative tools or state when-not-to-use conditions, so it falls short of full exclusion-based guidance, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds useful context by detailing what information is exposed (account, panel, cases with rights), setting expectations beyond the bare 'whoami' name.
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?
The description is just two sentences: the first directly states the tool's output, and the second offers practical advice on ordering. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool, the description fully explains the returned content (account, panel, cases with permissions) and how it fits into an agent's workflow. Without an output schema, this level of detail is both necessary and sufficient.
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?
The tool has zero parameters, and the schema is empty. Per the guidelines, the baseline for zero parameters is 4, and the description appropriately does not attempt to describe nonexistent parameters.
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 description clearly states that the tool returns the current account, connected panel, and accessible cases with their permissions. This is a specific and unambiguous statement of purpose. It distinguishes itself from sibling tools by focusing on the current session context rather than listing resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to call this tool first and mentions that afterwards cases can be referenced by name, providing clear when-to-use guidance. It does not explicitly mention alternatives or when not to use it, but the strong recommendation to invoke it first is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses two important behaviors: partial-update semantics ('остальные останутся как есть') and the onboarding gate where the API is fully closed until last name, first name, and birth date are present. This is rich, actionable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, then parameter-use instruction, then the critical onboarding context. Every sentence carries operational value and there is no redundant restatement of the title or schema.
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 six-parameter, zero-required mutation tool with no output schema, the description covers the essential selection and invocation context: what it changes, how to perform partial updates, and when it must be used for onboarding. It does not describe the response format or exclusions, but the schema and annotations carry enough of that load.
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?
The input schema already documents all six parameters, so the baseline is 3. The description adds meaningful semantics by instructing the agent to send only the fields to change and clarifying that unspecified fields retain their current values, going beyond the schema's individual field descriptions.
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 description names a specific verb ('меняет') and a precise resource ('данные учётной записи'), then enumerates exactly which fields are affected: ФИО, дата рождения, телефон, часовой пояс. This clearly distinguishes account_update from generic account utilities and sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for partial profile updates and specifically for the acquaintance/onboarding step while the API is closed. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to know when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond the annotations: the token is validated with a live request to Telegram and stored encrypted, and changing the token or mode restarts a running bot. This discloses non-obvious side effects and asynchronous behavior that an agent would 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the essential create/update distinction, then add two important behavioral facts. Every sentence earns its place and there is no redundant or vague wording.
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?
The description covers the main usage modes and important side effects, while the schema already documents all 9 parameters and the annotations cover the safety profile. It lacks an explicit note about return values or failure behavior, but with no output schema and strong schema coverage the description is still sufficient for correct invocation.
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 adds extra meaning for the bot parameter (absence means new, presence means update), token validation and encryption, and the restart effect of changing token or mode, going beyond the schema descriptions.
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 description clearly states the tool both connects a new bot and modifies existing bot settings, distinguishing these two modes by the presence of the bot parameter. This separates it from sibling bot tools like bots_delete, bots_control, or bots_reveal_token.
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 explicitly says to omit bot to connect a new bot and include bot to change settings, which gives clear context for the create-versus-update decision. However, it does not name alternatives such as bots_webhook_rotate or bots_control, so exclusion guidance relies on general tool knowledge rather than explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals important behavior: deletion destroys saved keys, deletion is blocked while the connection is still referenced, and the agent must first detach it from bots, knowledge bases, and AI Reply nodes. This is rich, non-obvious context that annotations alone do not provide.
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?
The description is only two sentences: the first front-loads the core destructive action, and the second compactly lists the necessary dependency-clearing steps. Every sentence earns its place, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with no output schema, the description covers the effect, the sensitive-data consequence, the blocking condition, and the exact steps to unblock it. This is sufficient for an agent to invoke the tool correctly and avoid failed calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add significant new direct meaning for the provider or case parameters, though it does mention provider_id in flows_save as part of the unblocking workflow. Baseline 3 is appropriate.
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 description starts with a specific verb and resource: 'Удаляет подключение вместе с сохранёнными ключами' — it clearly states what is deleted and that saved keys are also removed. This distinguishes it from sibling AI tools like ai_save, ai_list, and ai_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when deletion is blocked ('Пока сервис используют боты, панель удалить его не даст') and provides precise removal steps using sibling tools with parameter values: bots_save ai_provider=null, knowledge_save provider=null, and flows_save. This gives the agent clear conditions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds specific consequences: deletion of commands, variables, dialogues, and irreversibility. This goes beyond the annotation, giving the agent a full picture of the tool's impact.
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?
Three short sentences: the first states the core action, the second describes consequences, the third gives an alternative. Every sentence adds value and the description is front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 the destructive behavior, scope, and irreversibility. It also provides a contrast with the non-destructive alternative, making the tool's usage context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for bot, case, and confirm_name. The tool description does not add additional parameter-level details, so the baseline score of 3 applies.
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 description clearly states the tool removes the bot from the case along with commands, variables, dialogues, and correspondence, and that restoration is impossible. This distinguishes it from sibling tools like bots_save (used for temporary disablement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides an alternative for temporary disablement: 'use bots_save enabled=false.' This tells when not to use this tool and directs to the correct sibling, fulfilling the usage guideline requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint: true), the description explains that the token grants full control of the bot and that it should be handled carefully. This adds meaningful security context without contradicting annotations.
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?
Two-sentence description: first sentence states the action, second provides essential security guidance. No wasted words; information is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple token-reveal operation with no output schema, the description covers purpose, sensitivity, and usage restrictions. It is fully adequate for the agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'bot' and 'case' parameters. The description adds no extra parameter-level detail, which matches the baseline for high schema coverage.
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 description clearly states the tool returns the Telegram token in plain text ('Возвращает токен Telegram в открытом виде'). This is a specific verb + resource that distinguishes it from sibling tools like bots_get or bots_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to request the token only when the user directly asks for it and not to relay it unnecessarily. This gives clear when-to-use and when-not-to-use guidance, even though it doesn't name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (write, non-destructive), the description discloses that existing keys are updated, new ones created, and secret-marked values are not shown back. It also specifies key character constraints, providing valuable behavioral details.
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?
Three compact sentences, front-loaded with the main action, and every sentence adds essential information. No fluff or redundant repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema richness and annotations, the description fully complements the structured data. It covers core behavior, key format, secret handling, and update semantics, making the tool's purpose and constraints complete for an agent.
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?
The schema already covers all parameters (100% coverage), but the description adds key format constraints (Latin, digits, underscore, dot) not present in the schema. It also reinforces the behavior of the 'secret' field, adding meaning beyond the schema.
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 description states a specific verb ('Задаёт' - sets) and resource ('переменные' - variables for bot script texts), with concrete examples (prices, addresses, links). It clearly distinguishes this tool from siblings like bots_save or bots_control by focusing on content variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context through examples ('цены, адреса, ссылки') and explains the update/create behavior, implying when to use it. It does not explicitly name alternatives or exclude cases, but given the unique sibling scope, the usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds concrete details: which entities are destroyed, and that deletion cannot be undone ('Восстановить нельзя'). This gives the agent a clear picture of the irreversible destructive scope, which is more than the annotation alone.
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?
The description is just two sentences, both information-dense. The first states the action and its scope, the second states irreversibility and the alternative. There is no redundant or filler content, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema, this description is fully complete: it tells what is deleted, warns about irreversibility, and gives an alternative for a milder action. Combined with the schema's 100% parameter coverage, the agent has all the information needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (case, confirm_name) have full schema descriptions with 100% coverage. The description adds no additional parameter-level detail, so the baseline of 3 applies; there is no need for the description to repeat what the schema already provides.
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 description clearly states the tool deletes an entire case ('Удаляет дело целиком') and enumerates exactly what gets deleted (bots, scenarios, correspondence, participants, roles). It also distinguishes itself from archiving via cases_save, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative: 'Чтобы просто убрать дело из списка, используйте cases_save с archived=true' (to simply remove from list, use cases_save with archived=true). This tells the agent when not to use this tool, which is exactly the needed guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses that the entire correspondence is deleted and that restoration is impossible. It also clarifies the behavior of the alternative path (correspondence remains), which helps the agent understand the irreversible side effect.
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?
Three short sentences deliver the core action, the irreversible consequence, and the recommended alternative. There is no filler or repetition; the most important behavioral warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a required confirmation parameter, the description sufficiently explains what is deleted, that deletion cannot be undone, and what to do instead when permanent deletion is not desired. The schema covers parameter semantics and confirmation, so no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters 'case', 'dialog', and 'confirm_contact' are already documented in the schema. The tool description adds no additional parameter-level meaning, matching the baseline for high schema coverage.
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 description opens with a clear verb and resource ('Удаляет диалог') and specifies the destructive scope ('вместе со всей перепиской'). It also distinguishes itself from dialogs_update by explicitly contrasting permanent deletion with a non-destructive manual-mode alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when not to use this tool: if the bot should merely stop replying, the agent should call dialogs_update with mode=operator and ai_enabled=false instead. This explicitly routes to the alternative and explains the trade-off regarding preservation of the conversation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important side effects: by default the dialog switches to manual mode and is assigned to the user, the scenario stops until explicitly returned, and messages are saved even if Telegram rejects them. It also preconditions that the bot must be running and directs attention to the 'ошибка доставки' field. This is substantial behavioral detail with no contradiction to annotations.
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?
The description is three dense sentences with no filler. The purpose is front-loaded, followed by the most impactful behavioral caveat (manual mode takeover), and then the operational requirement and response field. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, the description covers the main behavior, the mode switch side effect, how to revert it, a runtime prerequisite, and an important response nuance. Although there is no output schema, the description names the critical response field to check. Nothing essential appears missing for correct invocation.
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 adds meaningful extra semantics: reply is an alternative to text, not combined with it ('Вместо text, а не вместе с ним'), take_over defaults to true, and case has a fallback resolution order. This elevates the parameter guidance beyond the schema.
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 description opens with a specific verb and resource: 'Отправляет сообщение человеку от имени бота' — sending a message on behalf of the bot. It clearly distinguishes the two input modes (own text vs. prepared reply from replies_list), separating it from related dialog tools like dialogs_update and dialogs_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the bot must be running, and the tool can send either free text or a prepared reply. It also references dialogs_update mode=bot as the way to return the dialog to the scenario, and mentions the delivery-error field. It does not explicitly state when not to use this tool, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes well beyond annotations by disclosing that dialogs are not saved, delays are skipped, external requests and service-chat messages are not executed, and AI nodes consume real model limits. This gives the agent critical behavioral information beyond the raw readOnlyHint/destructiveHint flags.
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?
Four dense, front-loaded sentences: purpose, behavior, parameter usage, and a warning. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description states what the tool reports (trigger, steps, bot response) and covers important side effects and safety-relevant behavior. Combined with full schema coverage, it is complete enough for correct selection and invocation.
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 baseline is 3. The description adds meaningful context for variables by explaining how they substitute accumulated conversation state to test branches and substitutions, which is not obvious from the schema alone.
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?
Description starts with a specific verb and resource: 'Проверяет сценарий без Telegram' and names the exact outputs (trigger fired, steps passed, bot's would-be reply). This clearly differentiates from sibling tools like flows_get, flows_save, or flows_publish.
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?
Clear context is provided: use it to simulate a scenario without Telegram, with the option to inject variables to test conditional branches and substitutions. It doesn't explicitly name alternative tools or state when not to use it, but the usage intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important non-obvious behavior beyond annotations: changed text triggers reassembly to prevent stale bot answers, and link materials live as snapshots unless refetch=true is used. This adds meaningful operational context and does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four dense sentences, front-loaded with the primary action, and contains no filler. Every sentence earns its place by adding a distinct and useful piece of context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and moderate annotation richness, the description covers the operation scope, key constraints, reassembly behavior, and the refetch snapshot lifecycle. It is sufficiently complete for an agent to decide when and how to invoke the tool.
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 adds extra semantics for refetch (page fetched once at addition, then lives as snapshot) and for text (triggers re-slicing), which goes beyond the schema's parameter descriptions.
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 description uses a specific verb and resource: 'Правит название и текст материала' (edits the title and text of a material). This clearly distinguishes it from sibling tools like knowledge_add_document or knowledge_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to edit an existing material's title/text, with automatic reassembly. It also explicitly states an exclusion — source type and link cannot be changed — and explains the refetch behavior for link materials, though it does not explicitly name alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the token is not revoked server-side, a key behavior beyond the annotations. It clarifies that the action is local and non-reversible through this tool, significantly aiding user expectations.
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?
The two-sentence description is concise and front-loaded, stating the core action first and adding essential nuance in the second sentence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, output-less tool, the description fully covers functionality, side effects, and the path to full revocation. It leaves no critical questions unanswered.
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?
With zero parameters, the baseline of 4 applies as there are no parameter details to elaborate on, and the description need not compensate for schema gaps.
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 description clearly states the tool erases a saved token locally, using the verb 'erase' and specifying the resource ('saved token') and scope ('on this machine'). It also distinguishes itself by noting the token remains valid, setting it apart from revocation tools.
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 implies usage when the user wants to log out on this machine only, and explicitly directs to the panel for full revocation. While it doesn't name sibling tools, the alternative path is clearly outlined, providing adequate when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses important behavioral traits beyond the annotations: the graph must be sent in full, a new revision is created only if the graph actually changed, templates with AI nodes require provider and knowledge_base, and a missing knowledge_base causes empty replies. Annotations are limited to high-level hints, so this description carries and fulfills the behavioral burden well.
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?
The description is compact and front-loaded: the first sentence states the core behavior, and each subsequent sentence adds a distinct operational constraint or pointer. There is no filler, and the capital emphasis on ЦЕЛИКОМ effectively highlights the most critical requirement.
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 12-parameter write tool, the description covers the most decision-critical details: create vs overwrite, full-graph editing flow, template requirements, and the distinction from publishing. It does not describe the return value or response format, and a few optional parameters like `copy_of` are left to the schema, but the schema is detailed enough to compensate.
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 adds meaning beyond the schema by explaining the create-vs-overwrite behavior of `flow`, the whole-graph requirement for `nodes`/`edges`, and the conditional relevance of `provider` and `knowledge_base` for templates. It does not cover every parameter, but the schema already does so thoroughly.
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 description immediately states the tool's dual purpose: without `flow` it creates a scenario from a template or graph, and with `flow` it overwrites an existing scenario. The verb+resource combination clearly distinguishes it from sibling tools like flows_get, flows_publish, and flows_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use flows_get before saving (to edit a single node) and explicitly states that saving does not publish a scenario, pointing to flows_publish as the alternative. This is direct when/when-not guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Аннотации уже объявляют readOnlyHint=true и destructiveHint=false, и описание не противоречит им. Дополнительно раскрыто поведение: записи идут от свежих к старым, в конце ответа перечисляются виды записей и их количества, старые записи панель удаляет сама.
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?
Все пять предложений несут полезную нагрузку: назначение, отличие от audit_list, порядок записей, фильтрация, ретенция. Ключевая идентификация вынесена в начало, нет воды и повторов схемы.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Для инструмента с 6 параметрами и без выходной схемы описание достаточно полно: объясняет, что возвращается, в каком порядке, как фильтровать и что журнал не хранит историю навсегда. Остальные детали параметров уже есть в схеме.
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?
Схема покрывает все параметры на 100%, поэтому базовая оценка 3. Описание добавляет смысл сверх схемы: level=error означает только сбои, вид (kind) сужает выборку, а в конце ответа перечисляются реально встречавшиеся виды — это помогает агенту выбрать корректные значения.
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?
Описание начинается с конкретной глагольной конструкции «Что делал сам бот» и перечисляет виды записей (запуски, обновления, ответы модели, ошибки). Явно отличает себя от audit_list, который пишет действия людей, что снимает неоднозначность среди братских инструментов.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Прямо указано, что на вопрос «почему бот молчит» отвечает именно этот журнал, а не audit_list. Также даны практические указания: фильтрация по kind и level, level=error оставит только сбои, и предупреждение, что журнал — недавняя история, а не архив.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses meaningful behavior: it saves nothing, limits the recipient list to the first 50 by freshness, reports how many recipients muted the bot, and flags risky message conditions such as empty selection, overly broad selection, and unknown substitutions. This is substantial context that is not visible from annotations alone.
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?
The description is three dense sentences with no filler: first it states the purpose and outputs, then the urgency rationale, then side effects and filter semantics. The most important operational fact is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description needs to convey what the tool returns, and it does: counts, the first 50 recipients, muted-recipient counts, and message-level warnings. It also covers side effects (none), the alternative for drafts, and default filter behavior, making it complete enough for an agent to invoke the tool correctly.
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 description coverage is 100%, so the parameters are already documented individually. The description adds valuable collective semantics by stating that the conditions are the same as those in the conversation list and that omitting all conditions means all bot interlocutors, which helps an agent reason about how the filter parameters combine.
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 description begins with 'Прикидка до отправки' ('estimate before sending'), naming a specific action and resource, then lists concrete outputs: matching conversation count, who qualifies (first 50 by freshness), how many muted the bot, and warning conditions. It also explicitly distinguishes itself from broadcasts_save ('черновик заводит broadcasts_save'), so an agent can separate it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use instruction: 'Разосланное не отзывают, поэтому смотреть надо здесь' — check here before sending because sent broadcasts cannot be recalled. It also names the alternative for saving a draft ('Ничего не сохраняет: черновик заводит broadcasts_save') and explains filter defaults ('ни одного условия означает всех собеседников бота').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the generic annotations, the description discloses meaningful behavior: drafts never send until started, started broadcasts are immutable via this tool, editing replaces selection conditions wholesale rather than merging them, and HTML markup is validated at save time because Telegram would reject unclosed tags. This is substantive behavioral context not available from annotations or schemas.
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?
The description is dense but efficient: five sentences, each carrying operational meaning, with the most important create-vs-edit distinction front-loaded. There is no filler or repetition of schema content.
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 15-parameter tool with no output schema, the description covers the workflow, state transitions, edit semantics, and validation. The only notable gap is that it does not mention what the tool returns (e.g., an identifier of the saved broadcast), which an agent might need when chaining calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, but the description adds crucial semantics on top: the `broadcast` parameter switches between creation and editing, and the edit path replaces all selection-related conditions instead of appending to them. It also ties `parse_mode` behavior to the panel-side HTML validation warning.
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 description states a precise action and object: without `broadcast` it creates a draft, with `broadcast` it edits an existing draft or a scheduled broadcast. It also distinguishes itself from the relevant siblings by naming `broadcasts_start` and `broadcasts_cancel`, so the agent cannot confuse it with launching or stopping a broadcast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to use the tool with and without the `broadcast` parameter, and gives a clear when-not-to-use rule: a started broadcast cannot be edited and must be stopped via `broadcasts_cancel`. It also documents the edit behavior for selection conditions, giving the agent a concrete decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, openWorldHint=true), the description explains the irreversible consequence: 'Отправленное не отзывается ни у одного получателя' (sent cannot be recalled), and reveals queueing, scheduling via run_at, and the all-recipients risk. This significantly exceeds the structured annotations.
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?
Four short sentences, each with a distinct purpose: queueing, irreversibility warning and preview, scheduling, and cancellation. The action 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with no output schema, this description is unusually complete: it covers the core action, the main risk and mitigation, scheduling semantics, and the follow-up cancel action. Nothing essential for a correct invocation is missing.
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?
The schema already documents every parameter (100% coverage), so the baseline is 3. The description adds rationale for confirm_title as an exact-title confirmation and clarifies scheduling behavior with run_at, adding semantic value beyond the schema.
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 description immediately states a specific action and scope: 'Ставит черновик в очередь' (puts a draft into the send queue), which clearly means starting a broadcast. It also distinguishes itself from adjacent siblings by referencing broadcasts_preview and broadcasts_cancel, and from broadcasts_save by emphasizing the draft is already prepared.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance: first use broadcasts_preview to check recipients, and use broadcasts_cancel for anything not yet sent. The warning that an empty selection means all bot interlocutors tells the agent when to be cautious and what to check beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![operbots-mcp MCP server](https://glama.ai/mcp/servers/uk-kd/operbots-mcp/badges/card.svg)](https://glama.ai/mcp/servers/uk-kd/operbots-mcp)

Score Badge

Copy to your README.md:

[![operbots-mcp MCP server](https://glama.ai/mcp/servers/uk-kd/operbots-mcp/badges/score.svg)](https://glama.ai/mcp/servers/uk-kd/operbots-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uk-kd/operbots-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server