zaytsv-bot-graph-mcp

Server Quality Checklist

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

Latest release: v0.11.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., list_graphs, create_graph, publish_graph), but there is overlap among graph modification tools (update_graph, edit_graph_live, patch_graph) and creation tools (create_graph, create_graph_from_template, import_funnel). Detailed descriptions help, but an agent must read carefully to choose the right one.
Naming Consistency4/5
The majority follow a consistent verb_noun pattern (list_graphs, create_graph, delete_graph, rename_graph), but there are exceptions like article_list instead of list_articles, graph_analytics, and dry_run that break the convention. Overall, naming is readable and mostly predictable.
Tool Count2/5
With 30 tools, the server is over-scoped. The core graph management could be handled in fewer tools, and the inclusion of blog article tools (article_list, article_get, article_publish, article_update) is unrelated to bot graphs. Many operations are fragmented, making the toolkit feel bloated.
Completeness4/5
The graph lifecycle is thoroughly covered: create, get, update, delete, publish, clone, copy, rename, set active, dry run, and template creation. File and bot management are also present. Minor gaps exist (e.g., no article_delete, no single-file retrieval), but these do not affect the core domain.
Average 4.1/5 across 30 of 30 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List of graphs' which implies a read-only operation, but it does not disclose pagination, ordering, whether archived graphs are included, or any other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no wasted words. It is a short noun phrase that conveys the resource type and scope, though it lacks a full sentence structure and additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of annotations/output schema, the description is under-specified. It identifies the resource (graphs) and scope (bot) but does not state the action explicitly, explain the parameter, or mention any return information, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter botId with no description, and schema coverage is 0%. The description's phrase 'of the bot' hints that botId identifies the bot, but it does not explain the parameter format, how to obtain it, or its role beyond that vague association.
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 lists graphs (scenarios) for a bot. It distinguishes from sibling tools like get_graph (singular) and create_graph by implying a plural listing operation, though it does not explicitly name any alternatives.
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 provided about when to use this tool versus alternatives. There is no mention of context, exclusions, or relationship to sibling tools like get_graph or list_channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return of the graph with id and DRAFT status, but omits side effects, permissions, or reversibility. For a creation tool, the absence of safety context is a significant gap.
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 short sentences with no unnecessary words. It is front-loaded and efficient, but the brevity leads to under-specification, trading completeness for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description is minimal and does not address error cases, prerequisites like an existing bot, or behavior on duplicate names. Without annotations, the agent is left without key context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for botId and name, and the description adds no information about these parameters. The agent must rely solely on parameter names, which are not explained, making it hard to know their exact purpose and valid values.
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 'Создать пустой граф (DRAFT) в боте' (create empty graph draft), specifying the verb and resource. It distinguishes from siblings like create_graph_from_template by emphasizing 'empty' and 'DRAFT'.
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 creating a blank graph, but it does not explicitly state when to use this tool over alternatives or any exclusions. It lacks guidance on prerequisites or when not to use it, so the agent must infer from the name 'empty'.
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?
No annotations are present, so the description must convey behavior. It adds useful context by listing output fields and clarifying the chatId semantics for the SUBSCRIBED condition. However, it does not explicitly state that the operation is read-only or disclose any permissions, pagination, or rate limits. For a list operation, the read-only nature is implied but not confirmed.
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 with no fluff. It front-loads the main purpose and adds one clarifying note about chatId. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output fields are enumerated, but the required input parameter botId is entirely undocumented. Since there is no output schema or annotations, the description is the only source of information, and the missing parameter guidance is a significant gap for a tool with only one input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema requires botId (string) but provides no description, and schema description coverage is 0%. The description does not mention botId at all, leaving the sole parameter completely unexplained. The agent receives no guidance on what value to pass.
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 explicitly states the tool lists channels/groups connected to a bot, a specific resource and verb. It also enumerates output fields (chatId, title, type, status, date), which distinguishes it from sibling tools like list_bots or list_bot_users.
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 only defines what the tool returns; it provides no guidance on when to use it versus alternatives such as list_bots or list_links. There is no mention of use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the HTTP method and the storage consequence, but does not disclose irreversibility, permission requirements, or error behavior, leaving significant behavioral ambiguity.
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 action verb, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and consequence, but lacks usage context and behavioral caveats. For a simple single-param tool, it's adequate but leaves gaps around permissions and edge cases.
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 has only one required string parameter, and the description adds that deletion is 'по id' (by id), which provides basic semantics. However, it doesn't detail id format or how to obtain it, so it's adequate but not rich.
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 the specific verb 'Удалить' (delete), identifies the resource ('файл из библиотеки /bots/files'), and includes the HTTP endpoint, clearly distinguishing it from sibling file operations like list_files and upload_file.
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 provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states the operation itself without contextual use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the core action and doesn't explain side effects (does it execute commands or just validate?), permissions, or return format. The mention of 'kind: command|callback|text' suggests possible execution, but the description lacks crucial 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but it is under-specified. The single sentence conveys the core purpose but omits essential parameter and usage details, making it too brief to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is far from complete. It doesn't cover parameter meanings, invocation patterns, or expected behavior, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond restating the 'kind' enum which is already in the schema. No explanation is given for graphId, value, presetTags, fromUsername, or presetVariables, leaving the agent to infer their semantics from names 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?
The description states a specific action: 'Run the scenario without publishing' (Прогнать сценарий без публикации). This clearly identifies the tool's purpose and distinguishes it from sibling tools like publish_graph, which publishes. The included 'kind' field hint adds specificity without confusion.
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: the tool is for running a scenario in a non-publishing mode, implying a testing or dry-run use case. While it doesn't explicitly mention alternatives, the 'without publishing' phrase strongly signals when to use this tool over publish_graph or other graph management tools.
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?
With no annotations, the description carries the transparency burden. It does disclose the return format (publishedGraphId or errors[] with code, nodeId, message), which provides useful behavioral context. However, it does not mention side effects, permissions, or whether the operation is reversible, leaving gaps.
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 includes the core action and return values without unnecessary words. Every element earns its place, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required parameter, no annotations, no output schema), and the description provides the essential action and return format. However, it lacks usage context, sibling differentiation, and error semantics beyond the error structure, so it is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter name 'graphId'. The single parameter is self-explanatory by name, but the description does not elaborate on its format, source, or relationship to other graph operations, so it only partially compensates for the low 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 uses a specific verb and resource ('Опубликовать граф' / 'Publish graph') and clearly distinguishes the tool from siblings by the action of publishing. It also mentions return values (publishedGraphId or errors), 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_graph or set_active_graph. It does not state prerequisites, conditions, or exclusions, leaving the user to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The word 'list' implies a read-only operation, but no details are given about pagination, sorting, limits, or any side effects. The description adds minimal context beyond the tool's 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 a single, concise sentence that is front-loaded with the core purpose. Every word earns its place, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description is thin. It lists the return fields but omits any context about authentication, error conditions, or how the list is ordered. For a simple list tool, this is adequate but not rich.
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?
This tool has zero parameters, so the baseline score is 4. The description adds no parameter information, but none is needed given the empty schema; it does mention return fields, which is helpful.
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 'List of user's bots' with specific fields (id, name, status), making the action and resource explicit. It differentiates from sibling tools like list_graphs and list_channels.
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 provided on when to use this tool versus alternatives. There is no mention of exclusions, preferred contexts, or comparisons to similar list tools.
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?
With no annotations, the description carries the full transparency burden. It does disclose the multi-step pipeline and the optional dry-run flag, suggesting a non-destructive preview or validation step. However, it remains vague on whether publish is irreversible, whether nodes/edges are replaced or merged, and what happens if both graph and graphFile are provided, leaving significant behavioral gaps.
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, dense sentences with all key information front-loaded. It lists the step sequence and the inline/file input options with no filler or redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's composite nature (6 parameters, nested graph object, no output schema, no annotations), the high-level overview is insufficient. Critical behaviors are missing: the ambiguous '/start' meaning, conflict handling for existing graphs, the role of name, and the response format are all left unexplained. The description is not complete enough for safe autonomous 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?
The description adds meaning to graph (inline) and graphFile (file path), and mentions dryRun as optional and publish as a step. Yet it does not explain the name parameter or the required botId, and schema coverage is only 17% (only graphFile has a description). Thus the description only partially compensates for the low 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 explicitly enumerates the composite action: 'Всё за раз: создать граф, залить узлы/рёбра, (опц.) dry-run /start, опубликовать'. This specifies the exact verb sequence (create, upload, optional dry-run, publish) and resource (graph), clearly distinguishing it from single-step siblings like create_graph or publish_graph.
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 phrase 'Всё за раз' implies this tool is meant for a one-call full pipeline, but it does not explicitly state when to choose it over chaining the individual sibling tools, nor does it mention any exclusions or alternatives. Usage context is implied rather than clearly spelled out.
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?
No annotations exist, so the description carries the burden. It discloses that the graph is created as a DRAFT and returns a graph with an id, which is helpful. However, it does not mention any prerequisites, permissions, or potential side effects beyond creation.
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 that convey the core action, the draft status, the template source, and the follow-up action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and undocumented parameters, yet the description covers only the template source and the returned id. It omits the role of botId and the optional name, leaving the tool insufficiently specified for a confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with no descriptions, and the description only hints at templateId via 'из шаблона'. botId and name are left unexplained, so the description does not compensate for the 0% 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 uses a specific verb ('Создать' = create) and identifies the resource ('граф из шаблона') and the draft status. This clearly distinguishes it from other graph creation tools like create_graph or clone_graph, which are 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?
It tells the user to see list_templates to know available templates, and instructs to edit further via update_graph. This implies a workflow but does not explicitly mention when to use this tool over create_graph or clone_graph, so guidance is present but not comprehensive.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It adds a meaningful trait: renaming published scripts does not affect execution. However, it omits other potential behaviors like idempotency, permission requirements, or side effects, making this only minimally adequate.
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 is concise and directly states the purpose and a key caveat. 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 simple two-parameter tool with no output schema, the description covers the most relevant context (published scripts, execution impact). It leaves out some operational details, but is reasonably complete given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the parameters beyond what the schema shows (graphId and name), nor does it add details like uniqueness constraints or format expectations. The meaning is largely inferred from the tool name.
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: 'Rename a script' (Переименовать сценарий), which maps directly to the tool name rename_graph. It adds a specific nuance (works for published ones) that distinguishes it from broader tools like update_graph.
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 noting that the tool works for published scripts and that renaming does not affect execution. It implies a safe use case but does not explicitly name alternatives or exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the access scope (public reading), the HTTP method (GET), and the response fields (title, content, excerpt, coverImage, viewCount). It does not mention error handling or rate limits, but the disclosed information is substantial.
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, efficient sentence that packs endpoint, access level, and return structure without redundancy. Every piece of information 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 tool with one parameter and no output schema, the description is complete: it explains what it returns and who can access it. It covers purpose, parameters (via the endpoint), and the result shape, enough for an agent 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?
The schema already provides 100% coverage for the single parameter, describing slug as the article path part. The description repeats 'by slug' and the endpoint, adding little semantic value beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (get article), resource (blog article), and access method (by slug). It includes the HTTP endpoint and distinguishes from sibling tools like article_list, article_publish, and article_update by focusing on single-article retrieval.
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 public reading of any article, including others', but does not explicitly contrast with sibling tools or state when to use this tool instead of listing or publishing. The context is clear but no exclusions or alternatives are named.
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?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior, pagination starting at page 0, default size 25, and search across name/username/id. It omits details like return format or error handling, but for a simple list operation this is solid.
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 then covers endpoint, optional parameters, and read-only nature in a highly efficient way. 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 list tool with no annotations and no output schema, the description covers the essential semantics: resource, pagination, search, and safety. It lacks return shape and error details, but these are minor for a basic GET list. The endpoint and parameter behavior 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?
Schema coverage is 0%, so the description must compensate. It explains page (starting at 0), size (default 25), and query (search by name/username/id). botId is not explicitly described but is implied by the endpoint path. This meaningfully adds beyond the bare schema.
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 (bot users/subscribers/leads) and indicates a paginated listing operation via the endpoint and 'постранично'. It distinguishes from sibling tools like list_bots and list_channels by explicitly naming the user resource, though it lacks an imperative verb like '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 provides clear context: it is a read-only paginated list with optional search by page, size, and query. It does not explicitly name alternatives or exclusionary conditions, but the context is sufficient for a straightforward list tool.
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?
Since no annotations are provided, the description carries the full burden. It discloses key behavioral traits: the clone is created as a new DRAFT with '… (copy)' in the name, and it is 'safe' for iteration, implying the original is unaffected. This adds useful context beyond the bare operation.
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 verb and resource. Every word contributes meaning, including the naming convention and use case. No wasted or redundant text.
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 one-parameter tool with no output schema, the description covers the essential aspects: the action, the result format (DRAFT with copy suffix), and the intended use case (safe iteration on published graphs). It does not mention edge cases or return values, but these are not critical for such a straightforward clone 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?
There is one parameter, graphId, and the schema description coverage is 0%. The description implies that graphId refers to the graph to clone, but it does not explicitly define the parameter or its format. The parameter name is self-explanatory, but the description could have added more clarity (e.g., whether it is an ID, path, or object).
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 ('Склонировать граф' - clone a graph) and specifies the result (a new DRAFT with '… (copy)' suffix). It distinguishes this from sibling tools like copy_graph by emphasizing the DRAFT creation and safe iteration 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?
The description provides clear context for when to use the tool: when you want to safely iterate over a published graph without modifying the original. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of perfect 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?
With no annotations, the description carries the burden of disclosure. It states 'Read-only,' revealing the non-mutating nature, and the GET method indicates a safe operation. It also explains the type of insight provided (user counts per node). However, it does not describe response structure, time range, or potential limitations, which would improve transparency further.
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, well-structured sentence that front-loads the core purpose, includes the endpoint, and explains the business value. Every phrase earns its place, 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?
For a simple 1-parameter analytics tool with no output schema, the description gives sufficient context: what it measures, how to interpret the insight, and the read-only nature. It lacks explicit return format details, but that is not mandatory given the tool's simplicity. The provided information covers the essential use case.
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 has 0% description coverage, so the description must compensate. It does not explicitly explain graphId, but the endpoint /graphs/{graphId}/analytics and the tool name make it recoverable. For a single self-explanatory parameter, this is adequate but not exemplary. The description adds minimal value beyond the schema, hence a 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's function: analytics of scenario progression by nodes, showing how many users reached each node and where the funnel drops off. It is specific and distinct from sibling tools like get_graph or list_graphs, which focus on graph structure or listing. The inclusion of the HTTP endpoint 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?
The description implies the tool is for analyzing funnel drop-off, giving clear context on when to use it. It explicitly marks the tool as read-only, which is a usage guideline for safe querying. However, it does not explicitly exclude alternatives or mention when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds context about the API endpoint and that it returns used/limit bytes plus ready URLs, but it does not explicitly state whether the operation is safe/read-only or describe the response format in detail.
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 the purpose front-loaded and no wasted words. It efficiently covers what, where, and why.
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 it is a simple parameterless list operation with no output schema, the description provides solid context: the resource, endpoint, usage information, and practical guidance on using returned URLs. Slightly more detail on the response shape would be helpful but is not critical.
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 coverage is trivially 100%, so the description has no parameter documentation burden. The baseline of 4 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 lists files in the /bots/files library, specifies the HTTP endpoint (GET /api/bots/media), and includes usage byte information. This distinguishes it from sibling list tools like list_graphs and list_channels.
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 taking ready-made URLs from this tool to avoid re-uploading the same content, providing a clear use case relative to upload_file. It does not explicitly mention when not to use it, but the guidance is sufficient.
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?
With no annotations provided, the description carries the transparency burden and explicitly states 'Read-only' and the GET method, signaling non-mutating behavior. It also discloses the return fields (code, labels, number of starts). It does not mention pagination or auth, but for a straightforward list tool these omissions are acceptable.
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 highly concise, combining the resource, endpoint, return fields, functional context, and safety note in two short sentences. Every element adds value, and it is front-loaded with the core 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 tool with one parameter and no output schema, the description covers the essential aspects: what the tool returns (code, labels, starts count), the type of data (tracking links with UTM), and the read-only nature. It could mention pagination or response format, but the description is sufficient for most use cases.
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 0%, but the only parameter botId is self-explanatory. The description refers to 'ссылки бота' (links of the bot), indicating botId identifies the bot. However, it does not elaborate on where to obtain botId or any constraints, leaving some burden unmet.
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 starting/tracking links for a bot, specifying the resource scope (links), the HTTP method (GET), and distinct characteristics (UTM, funnel entry points). This distinguishes it from sibling tools like list_graphs and list_channels by focusing on links and their role in funnels.
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 states that these links are points of entry into the funnel, giving clear context on when to use the tool (for accessing bot tracking links). It does not explicitly name alternatives or exclusions, but the functional context is sufficient for a simple list tool.
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?
With no annotations, the description carries the full burden. It discloses the key behavioral trait: the action switches the live scenario without needing to republish. It doesn't mention permissions or reversibility, but for a simple setter this is adequate 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 a single, front-loaded sentence with no wasted words. It conveys the action, resource, and a key differentiating constraint efficiently.
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 tool with two string params and no output schema, the description is sufficient. It covers the purpose, the requirement that the graph be published, and the benefit of avoiding republishing. It could add explicit parameter clarifications, but is otherwise 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 0%, so the description must compensate. It implies graphId is a published graph and botId is the bot, but doesn't explicitly define either. The parameter names are self-explanatory, and the description partially bridges the gap by linking them in 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 uses a specific verb 'Назначить' (assign) and clearly identifies the resource: which published graph is active for the bot. It also distinguishes from siblings by noting 'без перепубликации' (without republishing), separating it from publish_graph and edit_graph_live.
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: switching the live scenario without republishing, which implies when to use this over publish_graph. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
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?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful behavioral context: the token is saved and applied immediately without restart. However, it does not mention potential overwriting of an existing token, permission requirements, or any side effects, leaving some transparency gap.
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 purpose and source, while the second communicates the key behavioral trait. There is 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?
Given the low complexity of a single-parameter setter and the absence of an output schema, the description covers the essential context: what is saved, where the token comes from, and that it applies immediately. It omits minor details like overwriting behavior, but the tool is simple enough that this is not a major completeness gap.
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 fully describes the single 'token' parameter with its zmcp_ prefix, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that the token is user-created at /bots/mcp-tokens and that saving it takes effect immediately, which helps the agent understand the token's provenance and effect.
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 ('save') and a specific resource ('personal token'), and further specifies the token prefix (zmcp_) and its source (/bots/mcp-tokens). This uniquely distinguishes it from all sibling tools, none of which deal with token persistence.
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 for when to use this tool: when a user has created a personal token at /bots/mcp-tokens and it needs to be saved. It notes that the changes apply immediately without restart. It does not explicitly mention alternatives or when-not-to-use, but given the unique purpose, the guidance is sufficient.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key constraint (active graphs cannot be deleted), the resulting HTTP 409 status, and the remedy. It does not mention irreversibility or permission requirements, but the core behavioral risk is covered.
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, front-loaded with the primary action and immediately followed by the critical constraint and corrective action. 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 simple one-parameter delete operation, the description provides the essential operational context: what can be deleted, what cannot, the error behavior, and how to resolve it. No output schema exists, but none is critically needed for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a graphId string with 0% coverage from the description. The description does not explain how to obtain graphId, its format, or its role beyond the implied 'graph'. Given the low schema coverage, more parameter-level guidance was expected.
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 'Удалить граф' — a clear, specific verb and resource — and immediately distinguishes the tool's scope by warning that an active graph cannot be deleted. This clearly differentiates it from sibling delete_file and other graph-manipulation 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 explicitly states when the tool should not be used (active/published/bot-assigned graphs) and names the required alternative: 'сначала переключи активный через set_active_graph'. This gives the agent an explicit precondition and next step.
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?
With no annotations, the description carries the full burden. It states the output fields (id, name, description) but does not explicitly disclose read-only behavior or potential side effects. For a simple list operation, this is adequate but not rich—no mention of auth, caching, or data scope.
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 purpose and a brief, relevant use case. Every sentence earns its place with no redundancy or irrelevant details.
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 tool's simplicity (0 parameters, no output schema), the description is complete: it lists the returned fields (id, name, description) and a practical use case. There is nothing 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered by definition. The description correctly does not attempt to explain parameters, and the baseline for 0 params is 4. It adds no parameter-specific information because none 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 clearly states it lists ready-made funnel templates with id, name, and description, using a specific resource and scope. It is distinct from sibling tools like list_graphs and list_channels, and the tool name 'list_templates' reinforces the purpose.
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 a clear use case: 'Можно стартовать граф из шаблона вместо сборки с нуля' (you can start a graph from a template instead of building from scratch). It implies when to use the tool, though it does not explicitly mention alternatives 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?
With no annotations provided, the description carries the full burden. It discloses the key behavior: only the owner can update and others get 403. It also explains the optional title behavior (fallback to '# ...' in content) and that content is Markdown. While it doesn't mention the success response format, the ownership restriction and error case are significant additions beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, packing the core action, parameter details, and a strong warning into three short clauses. Every sentence contributes value: the PUT endpoint and id source, content/title rules, and ownership restriction. 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 three-parameter update tool with no output schema, the description covers the main contextual needs: where to find the id, how the title is handled, and the ownership restriction. It could mention the success response shape, but that's not critical given the simple scope and the sibling tools provide surrounding context.
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 covers id and content with descriptions, but title has none. The description adds crucial semantics: title is optional and if omitted is taken from a Markdown heading in content. It reinforces that content is Markdown and id comes from article_list, aligning with schema descriptions, but adds the default title logic.
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: 'Обновить СВОЮ статью по id' (update your article by id), specifies the HTTP method and endpoint (PUT /api/articles/{id}), and distinguishes itself from siblings like article_publish (create) and article_get (read). It explicitly mentions 'СВОЮ' (your own), differentiating ownership scope.
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 guidance on how to obtain the id ('id бери из article_list') and references article_publish for title behavior, implying that tool is for creation. It also warns that only the owner can update and non-owners will receive 403, which is a clear constraint. While it doesn't explicitly say 'use article_publish for new articles', the reference provides sufficient context.
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?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only' and the HTTP method (GET), and clarifies that only the user's own articles are returned. It does not mention pagination or rate limits, but for a simple read-only list, this is sufficient disclosure.
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 concise sentences: the first states the purpose and return fields, the second explains the significance of id and slug, and the third notes the read-only nature. Every sentence earns its place, with no 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?
Given the tool's simplicity and lack of an output schema, the description adequately explains the return fields (id, slug, title, viewCount, dates) and provides cross-references to related tools. It clarifies the scope ('own articles') and the read-only behavior, making it complete for this straightforward list endpoint.
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 has zero parameters, so the baseline is 4. The description correctly focuses on the output fields rather than parameters, since there are none to document.
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 'Список СВОИХ статей' (List of OWN articles), clearly specifying the action, resource, and scope. It also lists the fields returned and distinguishes itself from sibling list tools by the 'own' scope, making its 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?
The description provides clear context for use: listing the user's own articles. It also states that the returned 'id' is needed for article_update, linking to a sibling tool. However, it does not explicitly contrast with article_get for single-article retrieval, so it falls short of a full when-versus-alternatives explanation.
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?
With no annotations provided, the description carries the full burden. It discloses detailed behavior: content must be Markdown, title extraction from first '# Heading', cover fallback to first image, excerpt generation, and return of id/slug/public URL. This goes well beyond basic descriptions and fully informs the agent of side effects and defaults.
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 paragraph but front-loads the core purpose and packs essential behavior without fluff. It is somewhat lengthy, but every clause contributes to operational understanding. No wasted words, though it could be split for readability.
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 no output schema, the description explicitly states the return value (article with id and slug + public URL), which is helpful. It covers parameter behavior, creation semantics, and defaults. It omits explicit auth prerequisites and error scenarios, but these are largely context-independent and typical for a publish action, so completeness is high.
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, but the description adds significant meaning: it explains Markdown syntax for content, how title is derived if omitted, and the fallback logic for cover and excerpt. This enriches each parameter beyond schema descriptions, justifying a score above baseline.
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 'Опубликовать НОВУЮ статью' (publish NEW article) with the endpoint (POST /api/articles), distinguishing it from sibling tools like article_update and article_get. It specifies the exact resource (blog articles) and verb (publish), leaving no ambiguity about its function.
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 strongly implies usage for creating new articles (emphasizing 'НОВУЮ') and provides context about how to use it (e.g., optional title, cover, excerpt). It does not explicitly name alternatives or exclusions, but the distinct 'new' semantics and detailed behavior serve as clear guidance versus update/get/list siblings.
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?
With no annotations, the description carries the full burden and does a good job: it discloses the token-limit risk for large graphs and explains exactly what summary:true and saveToFile return (compact summary with id/type/title/positions+edges, or a written file plus summary+path). It also notes the side effect of saveToFile (writing to disk). It does not cover error conditions or permissions, but for a getter this is adequate.
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 that front-loads the primary action and then adds conditional guidance. Every clause carries useful information—no filler. It is slightly long but acceptable because it covers two distinct alternate behaviors and a follow-up workflow.
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 is a simple getter but with two alternate modes and a future editing step. The description covers both modes, explains when to use them, and mentions the follow-up tools. It does not describe the structure of the returned graph JSON, but that would be better left to an output schema; for a retrieval tool with no output schema, this is sufficient context.
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 describes summary and saveToFile, but the description adds context beyond the schema: it ties summary to large-graph handling and specifies the exact content of the compact summary (id/type/title/positions + edges). It also explains saveToFile's return behavior and its place in the edit workflow. graphId is self-evident from the name and required field.
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 the specific verb-resource pair 'Получить граф по graphId' (get graph by graphId), which clearly identifies the action and target. It distinguishes itself from sibling tools by mentioning the mode alternatives (summary/saveToFile) and the follow-up tools update_graph/edit_graph_live, making its scope unique.
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 the alternative modes: 'Для БОЛЬШИХ графов ... используй summary:true ... или saveToFile' (for large graphs use summary or saveToFile). It also names the follow-up tools (update_graph/edit_graph_live) for editing and re-uploading, providing clear context not just for this tool but for the surrounding workflow.
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?
With no annotations provided, the description carries the transparency burden. It reveals the tool is informational (shows status and instructions), implying no destructive side effects. However, it does not explicitly state that it is read-only or describe any potential failure modes, though the strong implication of a status/info tool makes a 4 appropriate.
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 one concise sentence that packs the action, resource, and usage guidance into a tight, front-loaded structure. 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 no parameters and no output schema, the description fully covers what the tool does and when to use it. It is complete for its simple informational purpose and fits well within the sibling context.
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 is empty (0 parameters), so there are no parameter semantics to explain. The baseline for 0 params is 4, and the description need not add anything further.
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 'Показать' (show) and identifies the resource: authorization status and step-by-step instructions. This clearly distinguishes it from all sibling tools, none of which focus on auth status or setup guidance.
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 the tool: 'Вызывай первым, если пользователь не знает, что делать, или при ошибке доступа' (call first if the user doesn't know what to do, or on access error). This provides clear context but does not mention when not to use it or name alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'PUT, сырой replace без бэкапа' (raw replace without backup), which is a critical destructive trait. It does not mention all side effects (e.g., whether graphId is required or what happens to omitted fields), but the destructive nature is transparent.
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 core action and method, followed by essential caveats and input options. Every sentence adds value with no fluff.
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 7 parameters, no output schema, and no annotations, the description covers the main purpose, destructive behavior, input alternatives, and sibling distinction. It doesn't explain every parameter or return value, but for a replace operation the key context is present. The absence of output schema lowers the burden, making this fairly 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?
Schema description coverage is only 14%, but the description compensates by explaining graphFile in detail ('путь к локальному файлу — НЕ нужно слать граф инлайном, удобно для больших графов') and clarifying that graph-container or nodes/edges are accepted alternatives. This adds meaning beyond the bare schema for the primary parameters, though some (name, canvasMeta) are not explained.
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 explicitly states what the tool does: 'Залить узлы/рёбра в граф' (upload nodes/edges to graph) with 'PUT, сырой replace без бэкапа' (PUT, raw replace without backup). This is a specific verb+resource+method that clearly distinguishes it from the sibling tool edit_graph_live, which is for editing existing/live scenarios.
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 provides explicit guidance on when NOT to use this tool: 'Для правок СУЩЕСТВУЮЩЕГО/живого сценария используй edit_graph_live' (For editing an existing/live scenario, use edit_graph_live). It also clarifies accepted input formats (graphFile, graph container, or nodes/edges), making the usage context clear.
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?
With no annotations provided, the description fully discloses behavioral traits: in-place editing (id unchanged), auto-backup to a rolling graph, open editors receive external_update, bot re-reads from DB, and the critical warning that PUT does not validate. This goes beyond simple mutation and covers side effects and safety.
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 but information-dense. Each sentence adds distinct value: purpose, non-behavior, effects, usage context, and validation warning. It is well-structured with emphasis markers (РЕКОМЕНДОВАННЫЙ, ВАЖНО) and 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?
Given the complexity (live editing, backup, validation concerns), the description covers all essential aspects: what it does, effects on open editors and the bot, when to use, and prerequisites. It also references sibling tools and validation workflow, making it complete for an agent to select and invoke 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 low (25% with only backup and graphFile having descriptions). The description adds meaning for graphId (targets the existing graph that is edited in place) and backup (auto-backup behavior), but does not elaborate on other parameters like name, edges, nodes, graph, canvasMeta. While the high-level context helps, it does not fully compensate for the undocumented 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 the tool's purpose: it edits an existing (live) graph in place on the same graphId, with auto-backup, and explicitly distinguishes itself from cloning/publishing. The verb 'edit' and resource 'live graph' are specific and differentiate 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 provides explicit when-to-use guidance: 'Используй ВМЕСТО clone+publish, когда нужно поправить сценарий, который уже открыт/в проде.' It also states what it does NOT do (no clone, no new active graph) and gives a validation precondition (run validate.mjs and dry_run).
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?
With no annotations provided, the description carries the full burden and does excellently: it discloses the endpoint, upload-from-URL behavior, return payload structure, size limit, allowed file types (including SVG prohibition), and HTTP 402 error on quota exhaustion. This goes well beyond basic parameters.
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 yet efficient, front-loading the core purpose in the first sentence, then parameter usage, return value, downstream usage, and constraints. Every sentence adds value, and it is appropriately sized for the tool's complexity.
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 annotations or output schema, the description is self-contained: it explains the returned fields, how to use the URL in SEND_MESSAGE and SEND_PHOTO, file type restrictions, and error behavior. This is a complete picture 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?
The schema already has 100% coverage with descriptions for all three parameters, so baseline is 3. The description adds meaningful semantics beyond schema: it clarifies that path and url are mutually exclusive (OR), and it provides allowed types and size limits that constrain parameter values.
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: 'Загрузить файл в библиотеку /bots/files ... и получить публичный URL для вставки в сценарий.' It specifies the verb (upload), resource, endpoint, and intended outcome, distinguishing it from sibling tools like list_files and delete_file.
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: when to use (to upload a file and get a URL for scenarios) and how to pass parameters (path OR url). However, it does not explicitly mention when not to use it or name alternative tools, so it earns 4 rather than 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?
With no annotations, the description fully carries behavioral disclosure. It reveals the return shape ({graphId, sourcePlatform, targetPlatform, notes[]}), explains notes semantics (TRANSFORM, MANUAL, INFO), details auto-adaptation behavior for Telegram⇄MAX, notes that Instagram copies lack transformations and are flagged at publication, and clarifies preview's non-destructive nature. This exceeds typical 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 dense yet structured, using semicolons and dashes to cover return value, notes severity, platform-specific transformations, preview mode, and restrictions in a compact block. Every sentence contributes unique information, and the most important action 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?
Given the tool's complexity (cross-platform copying, transformations, preview mode) and absence of an output schema, the description thoroughly covers return values, notes semantics, platform behaviors, and edge cases like Instagram allowlisting. It also clarifies the relationship with publish_graph ('несовместимые узлы будут отмечены при публикации'), making it contextually 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?
Schema coverage is 67%, and description adds meaning beyond the schema: it clarifies targetBotId must be a different bot (same bot forbidden) and elaborates preview=true as a compatibility check with no saving. The graphId parameter, however, is left without additional explanation beyond its obvious role as the source graph ID, an acceptable gap.
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+resource: 'Скопировать граф в ДРУГОГО бота' (copy graph to another bot), clearly stating the operation and scope. It explicitly distinguishes from sibling clone_graph by noting 'для дублирования есть clone_graph' (for duplication there is clone_graph), eliminating ambiguity.
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 provides explicit when-not-to-use guidance: 'Тот же бот запрещён' (same bot is forbidden) and redirects to clone_graph. It also explains when to use preview mode (preview=true for compatibility check only) and distinguishes platform-specific behavior for Telegram/MAX vs Instagram, giving clear context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool modifies the graph in place, performs string replacements, validates the result, and uploads back with an auto-backup. It also explains preview mode (only count matches, no save) and immediate application of changes. This is thorough and honest about the mutation 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 dense yet efficient, front-loading the core mechanism and then providing usage guidance and parameter semantics. Every sentence adds value: purpose, when-to-use, replacements behavior, preview mode, and immediate application. No fluff or 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?
For a mutation tool with no output schema or annotations, the description is quite complete: it explains the operation, parameters, and side effects. However, it does not explicitly state what the tool returns on success (e.g., count of replacements or confirmation), which is a minor gap. Also, there is slight ambiguity about 'active graph' vs graphId, but overall it is sufficient for selection and invocation.
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?
Schema coverage is 50%, but the description strongly compensates by explaining replacements structure {find, replace}, emphasizing all occurrences, and advising specificity of find. It also clarifies graphId's role as the graph identifier. The preview and backup parameters are already described in the schema, so the description adds meaning where 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 clearly states the tool's purpose: patch a large/live graph by applying string replacements server-side without sending the entire graph. It uses a specific verb ('patch') and resource ('graph'), and distinguishes itself from siblings like update_graph and edit_graph_live by explicitly stating it does not transmit the whole graph.
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 says when to use this tool: when the graph is too large to pass whole via update_graph/edit_graph_live. It also provides concrete use cases (changing channel IDs in SUBSCRIBED conditions, button links, texts). Alternatives are named, making the choice clear.
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:

[![zaytsv-mcp MCP server](https://glama.ai/mcp/servers/skiddgoddamn/zaytsv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/skiddgoddamn/zaytsv-mcp)

Score Badge

Copy to your README.md:

[![zaytsv-mcp MCP server](https://glama.ai/mcp/servers/skiddgoddamn/zaytsv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/skiddgoddamn/zaytsv-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/skiddgoddamn/zaytsv-mcp'

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