Webasyst MCP Server

by emmy-design

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Webasyst components (apps, plugins, themes, widgets) or development tasks, but some overlap exists, such as multiple 'create' tools for different plugin types that could be confused if the agent doesn't carefully read descriptions. The tools are generally well-differentiated by their target domains.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. Verbs like 'create', 'get', 'list', 'generate', and 'run' are applied predictably across different nouns, making the set easy to navigate and understand.
Tool Count2/5
With 38 tools, this is an excessively large set for a single server, likely overwhelming for agents and indicating poor scoping. While Webasyst is a complex platform, the count suggests fragmentation of functionality that could be consolidated into fewer, more versatile tools.
Completeness5/5
The tool set provides comprehensive coverage for Webasyst development, including creation, analysis, configuration, and management of apps, plugins, themes, widgets, and system settings. It supports the full lifecycle from setup to deployment, with no obvious gaps in the domain.
Average 2.6/5 across 38 of 38 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('analyze') without explaining what the tool does operationally—such as whether it performs static analysis, runtime checks, or generates outputs. Critical details like permissions, side effects, or output format are missing, making it inadequate for a tool with parameters.
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 a single phrase, which is concise but under-specified. While it avoids unnecessary words, it lacks the structure needed for clarity—such as front-loading key details or breaking down components. It's brief but not effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is severely incomplete. It doesn't explain the tool's purpose in context, parameter roles, behavioral traits, or expected outcomes. This leaves the agent unable to understand or invoke the tool correctly.
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?
Schema description coverage is 0%, and the description provides no information about the three parameters ('project_path', 'analysis_type', 'generate_report'). It doesn't explain what these parameters mean, their expected values, or how they influence the analysis. With zero compensation for the schema gap, this fails to add any semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Проанализировать проект Webasyst' (Analyze Webasyst project) states a general action but lacks specificity. It mentions the resource ('Webasyst project') but doesn't clarify what analysis entails or how it differs from sibling tools like 'check_project_compliance' or 'validate_ui_usage'. This is a tautology that restates the tool name without adding meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With many sibling tools available (e.g., 'check_project_compliance', 'get_app_info'), the description fails to indicate appropriate contexts, prerequisites, or exclusions. This leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('create') without any information about permissions needed, whether this is a read/write operation, what happens after creation, error conditions, or output format. This is inadequate for a tool that presumably creates something.
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 extremely concise (two words), which could be efficient if it were informative. However, this brevity results in under-specification rather than true conciseness. It's front-loaded but fails to provide necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 undocumented parameters, no annotations, no output schema, and many similar sibling tools, the description is completely inadequate. It doesn't explain what a 'shop report' is, what the parameters do, what the tool returns, or how it differs from other creation tools in the system.
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?
Schema description coverage is 0%, meaning none of the 3 required parameters (report_key, report_title, webasyst_path) are documented in the schema. The description provides no information about what these parameters mean, their format, constraints, or examples. This leaves all parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать отчет Shop-Script' is a tautology that restates the tool name in Russian ('create shop report'), providing no additional specificity about what the tool actually does. It doesn't distinguish this from sibling tools like 'create_shop_plugin' or 'create_shop_theme', leaving the purpose vague beyond the basic verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools for creating various Shop-Script components (plugins, themes, etc.), the description offers no context about what a 'shop report' is, when it's needed, or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. The description only states the basic action ('create') without any information about side effects, permissions required, rate limits, error conditions, or what happens after creation (e.g., whether the widget becomes active immediately). For a creation tool with 8 parameters, this lack of behavioral 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase in Russian—which could be seen as efficient. However, it's under-specified rather than appropriately concise; it fails to provide necessary context for a tool with 8 parameters. While front-loaded, it doesn't earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 3 required), lack of annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the name, provides no parameter guidance, no behavioral context, and no usage guidelines. For a creation tool in a system with many similar tools, this leaves critical gaps in understanding.
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 description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description provides no information about any parameters—not even the three required ones (widget_name, widget_title, webasyst_path). This leaves all parameters completely undocumented, forcing the agent to guess their purposes and formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать виджет для Site' (Create widget for Site) is a tautology that essentially restates the tool name 'create_site_widget' in Russian. While it indicates the verb ('create') and resource ('widget for Site'), it lacks specificity about what kind of widget or what 'Site' refers to. It doesn't distinguish this tool from sibling tools like 'create_widget' or 'create_site_block'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools with similar names (e.g., 'create_widget', 'create_site_block', 'create_site_plugin'), but the description offers no context about differences, prerequisites, or appropriate scenarios for this specific tool. This leaves the agent guessing about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It does not indicate if this is a read/write operation, what permissions are needed, whether it modifies files, or any side effects (e.g., overwriting existing .htaccess). This leaves critical behavioral traits unspecified.
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 a single phrase, which is concise but under-specified rather than efficiently informative. It lacks structure or front-loading of key details, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of file generation, no annotations, no output schema, and incomplete parameter documentation, the description is severely inadequate. It does not cover behavior, output, or context, making it incomplete for effective tool use.
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 1 parameter with 0% description coverage, and the tool description adds no semantic information about 'root_path'. It does not explain what 'root_path' represents (e.g., filesystem path, web root), its format, or constraints, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Сгенерировать .htaccess' (Generate .htaccess) restates the tool name 'generate_htaccess' in a different language, making it tautological. It specifies the resource (.htaccess file) but lacks a clear verb or specific action details, failing to distinguish from sibling tools like 'generate_nginx_vhost' or 'create_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention prerequisites, context (e.g., web server configuration), or exclusions, leaving the agent with no usage direction compared to siblings like 'generate_nginx_vhost' or 'setup_seo_optimization'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action ('generate') without any details about what the tool actually does behaviorally—such as whether it creates a file, outputs text, requires permissions, has side effects, or handles errors. For a tool that likely produces configuration files, this lack of transparency is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase in Russian—with no wasted words. It's front-loaded and gets straight to the point, though this brevity contributes to its inadequacy in other dimensions. For conciseness alone, it's optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating configuration files with 3 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It doesn't cover behavior, parameters, usage, or output, making it inadequate for an AI agent to understand and invoke the tool correctly.
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?
Schema description coverage is 0%, meaning none of the three parameters (domain, root_path, php_version) are documented in the schema. The description adds no information about these parameters—it doesn't explain what they represent, their formats, or how they influence the generated config. This leaves all parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Сгенерировать nginx-конфиг' (Generate nginx config) is a tautology that essentially restates the tool name 'generate_nginx_vhost' in Russian. It specifies the verb 'generate' and resource 'nginx config', but lacks specificity about what type of nginx config (virtual host configuration) and doesn't differentiate from sibling tools like 'generate_htaccess' or 'get_routing_config'. The purpose is clear at a basic level but overly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for web server setup), or compare to sibling tools like 'generate_htaccess' or 'get_routing_config'. There's no indication of when this tool is appropriate or what scenarios it's designed for.
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 of behavioral disclosure. 'Создать' (Create) implies a write/mutation operation, but the description doesn't disclose any behavioral traits such as permissions required, whether it's idempotent, what happens on failure, or side effects. It lacks crucial context for a creation tool, leaving the agent with minimal operational insight.
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 a single phrase 'Создать action или controller', which is concise but under-specified rather than efficiently informative. It's front-loaded but lacks necessary detail, making it feel incomplete rather than optimally brief. The structure is minimal but fails to earn its place by adding insufficient value.
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 complexity of a creation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what an 'action' or 'controller' is, the expected outcomes, error handling, or how it fits into the broader context of sibling tools like create_app_structure. For a mutation tool with rich parameters, this minimal description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all parameters documented in Russian (e.g., 'ID приложения' for app_id). The description adds no additional meaning beyond the schema, as it doesn't explain parameter relationships, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать action или controller' (Create action or controller) is a tautology that essentially restates the tool name 'create_action' in Russian. It doesn't specify what an 'action' or 'controller' is in this context, what resource it creates, or how it differs from sibling tools like create_app_structure or create_model. The purpose is vague and lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or relationships with sibling tools (e.g., create_app_structure might be a prerequisite, or create_model might be for different resources). There's no explicit or implied usage context, making it misleadingly simplistic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It only states the action ('create') without any details on permissions, side effects, error handling, or output format. This is inadequate for a tool that likely performs a write operation, lacking critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It lacks details on behavior, parameters, usage context, and expected outcomes, making it insufficient for effective tool invocation.
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 description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description adds no information about what the parameters mean (e.g., 'plugin_name', 'webasyst_path'), their formats, or constraints, failing to compensate for the schema gap.
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 action ('Создать' meaning 'Create') and the resource ('плагин Shop-Script' meaning 'Shop-Script plugin'), making the purpose understandable. However, it doesn't differentiate from similar sibling tools like 'create_payment_plugin' or 'create_site_plugin', which would require more specificity to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for creating plugins (e.g., 'create_payment_plugin', 'create_site_plugin'), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
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 of behavioral disclosure. 'Создать' (Create) implies a write/mutation operation, but the description doesn't disclose any behavioral traits such as permissions required, whether it's idempotent, what happens on failure, or what the output might look like. It lacks critical context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Russian that directly states the tool's purpose without any fluff or unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of a creation tool with 4 parameters, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks essential details about behavior, parameters, and output, making it inadequate for an AI agent to use the tool effectively without additional context or trial-and-error.
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 4 parameters with 0% description coverage, meaning none are documented in the schema. The description provides no information about any parameters, not even hinting at what 'block_name', 'block_title', 'block_category', or 'webasyst_path' mean or how they should be used. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать блок конструктора Site' (Create a Site constructor block) states a clear verb ('create') and resource ('Site constructor block'), which is better than a tautology. However, it's somewhat vague about what a 'Site constructor block' actually is, and it doesn't distinguish this tool from sibling tools like create_site_plugin, create_site_theme, or create_site_widget, which all appear to create different site-related components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for creating site-related components (e.g., create_site_plugin, create_site_theme, create_site_widget), but the description doesn't explain what makes a 'block' different or when it's appropriate. No prerequisites, exclusions, or context are mentioned.
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 of behavioral disclosure. It only states the action ('create') without detailing permissions needed, whether it's idempotent, what happens on failure, or the expected output format. For a creation tool with 9 parameters, this leaves critical behavioral traits unspecified.
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, concise sentence in Russian ('Создать тему для Site'), which is appropriately brief and front-loaded. However, it's overly terse for a tool with 9 parameters and no other documentation, bordering on under-specification rather than optimal 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?
Given the complexity (9 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the tool's scope, parameter usage, behavioral expectations, or how it differs from similar tools. This inadequacy could hinder an agent's ability to invoke the tool correctly.
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 schema provides no parameter details. The description adds no information about what parameters like 'theme_name', 'color_scheme', or 'webasyst_path' mean or how to use them. It fails to compensate for the lack of schema documentation, leaving all 9 parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать тему для Site' (Create theme for Site) states the basic verb ('create') and resource ('theme for Site'), making the purpose understandable. However, it's vague about what kind of theme (e.g., visual design, layout) and doesn't distinguish it from sibling tools like 'create_theme' or 'create_shop_theme', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_theme' or 'create_shop_theme'. It lacks context about prerequisites, target scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
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 'Создать/обновить' (create/update), implying a mutation, but doesn't disclose behavioral traits such as permissions required, whether it's idempotent, what happens on conflicts, or output format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence in Russian, front-loaded with the core action. It wastes no words, making it appropriately concise. However, the structure is minimal and could benefit from slight elaboration for clarity, but it earns high marks for brevity.
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 complexity (mutation with 2 parameters), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain the PO template's purpose, parameter semantics, or behavioral context, leaving significant gaps for an agent to understand and use the tool effectively.
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 adds no meaning beyond the schema, failing to explain what 'app_id' and 'locale' represent (e.g., app identifier and language code) or their impact. With 2 parameters and no schema descriptions, this leaves semantics unclear, scoring below the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Создать/обновить' meaning 'Create/update') and resource ('PO шаблон для приложения' meaning 'PO template for application'), which clarifies the tool's purpose. However, it's vague about what a 'PO template' entails and doesn't differentiate from siblings like 'create_theme' or 'create_ui_component', which might involve similar template creation. The description is functional but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'create_app_structure', 'create_theme', and 'create_ui_component', there's no indication of context, prerequisites, or exclusions. It fails to help an agent decide between this and other creation/update tools in the set.
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 the full burden of behavioral disclosure. It hints at configuration tasks but lacks details on permissions needed, whether it modifies files or just generates recommendations, potential side effects (e.g., overwriting existing files), or error handling. This is inadequate for a tool with multiple parameters and no output schema.
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 concise with a single phrase, avoiding unnecessary words. However, it's under-specified rather than efficiently informative, as it lacks critical details needed for effective tool use, slightly reducing its structural value.
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 complexity (4 parameters with nested objects, 0% schema coverage, no output schema, and no annotations), the description is incomplete. It doesn't cover parameter meanings, behavioral traits, or expected outcomes, making it insufficient for an AI agent to reliably invoke this tool.
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 but fails to do so. It doesn't explain any of the 4 parameters (e.g., what 'site_path' refers to, what 'features' array contains, the purpose of 'analytics_codes' object, or what 'webasyst_path' is). This leaves parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Базовые SEO-настройки (robots/sitemap)' states the tool configures basic SEO settings for robots and sitemap, which is a clear purpose. However, it's vague about the exact actions (e.g., creating, updating, or validating files) and doesn't distinguish from sibling tools like 'generate_htaccess' or 'create_site_plugin' that might handle related web configurations.
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. The description doesn't mention prerequisites, context (e.g., during site setup or maintenance), or exclusions, leaving the agent to infer usage from the tool name alone among many sibling tools.
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 full burden. It implies a read-only analysis ('check'), but doesn't disclose behavioral traits such as what 'compliance' means, whether it's a quick scan or deep audit, if it requires specific permissions, or what the output format might be. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose. It's front-loaded with no wasted words, making it appropriately concise for its limited content.
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 complexity of a compliance check tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on what 'basic compliance' entails, how results are returned, or interaction with sibling tools, making it inadequate for informed agent use.
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 mentions 'UI/локализации' (UI/localization) but doesn't explain the 'project_path' parameter—what it expects (e.g., file path, directory, project ID) or how it relates to the compliance check. The description adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Проверить базовое соответствие UI/локализации' (Check basic UI/localization compliance) states a clear verb ('check') and target ('UI/localization compliance'), but it's vague about what 'basic compliance' entails and doesn't distinguish from siblings like 'validate_ui_usage' or 'analyze_project'. It provides a general purpose without specificity.
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. With siblings like 'validate_ui_usage' and 'analyze_project', the description lacks context on prerequisites, exclusions, or comparative use cases, leaving the agent to guess based on tool names alone.
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 of behavioral disclosure. 'Compile' implies a write operation that creates .mo files, but the description doesn't specify whether this overwrites existing files, requires specific permissions, or has side effects (e.g., affecting app functionality). It also omits details like error handling or output format, leaving the agent with insufficient context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian ('Скомпилировать .mo из .po'), which translates to 'Compile .mo from .po'. It's front-loaded with the core action and avoids unnecessary words, making it easy to parse quickly. There's no wasted verbiage, and it directly states the tool's function without redundancy.
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 complexity (a compilation tool with 2 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It fails to explain key aspects like parameter meanings, behavioral traits (e.g., file I/O effects), or expected outcomes. For a tool that likely involves file system operations, this omission could lead to misuse or errors by the agent.
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 0% description coverage, so the description must compensate by explaining the parameters. It mentions '.mo' and '.po' but doesn't link them to 'app_id' or 'locale', leaving the agent to guess how these parameters relate to the compilation process. For example, it's unclear if 'app_id' identifies the source .po file or target location, or what 'locale' specifies in this context. This gap reduces usability significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('compile') and the resource transformation ('.mo from .po'), which clarifies the tool's purpose. However, it doesn't specify what '.mo' and '.po' files are in this context or how they relate to the input parameters, leaving some ambiguity. It also doesn't differentiate from sibling tools like 'generate_po_template' or 'prepare_release_bundle', which might involve similar file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing .po files), context (e.g., part of a localization workflow), or exclusions (e.g., not for creating .po files). Given the sibling tools include 'generate_po_template', there's a missed opportunity to clarify the relationship between generating and compiling translation files.
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 full burden. It states 'create' which implies a write/mutation operation, but doesn't disclose behavioral traits such as permissions needed, whether it's idempotent, what happens on failure, or if it modifies existing resources. This is a significant gap for a creation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian, front-loaded with the core action. There's no wasted verbiage, though it could benefit from more detail given the lack of annotations and sibling differentiation.
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 complexity of creating an app structure (implied mutation), no annotations, no output schema, and many sibling tools, the description is incomplete. It doesn't explain what 'structure' means, the return value, or how it differs from similar tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for each parameter (app_id, app_name, description). The description adds no additional meaning beyond the schema, such as format constraints or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать структуру нового приложения' (Create structure of a new application) states a clear verb ('create') and resource ('structure of a new application'), but it's vague about what 'structure' entails compared to siblings like 'create_generic_app' or 'create_app'. It doesn't specify if this is for scaffolding, configuration, or something else, making it less distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_generic_app' or 'create_app' (implied from siblings). There's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.
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 of behavioral disclosure. It implies a creation/mutation operation ('create'), but doesn't specify permissions needed, side effects, error handling, or what happens if the model already exists. This is a significant gap for a tool that likely modifies system state, leaving the agent with insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian, front-loaded with the core action. There's no wasted text, but it could benefit from slightly more detail to improve clarity without losing 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?
Given no annotations, no output schema, and a vague description, this is incomplete for a tool that creates database models. It lacks details on what the model does, how it's used, or what the result looks like. Sibling tools suggest a development context, but the description doesn't leverage this, leaving gaps in understanding the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('app_id' and 'table_name'). The description doesn't add any meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate since the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать модель для работы с БД' (Create a model for working with the database) states a clear verb ('create') and resource ('model'), but it's vague about what type of model or what 'working with the database' entails. It distinguishes from siblings like 'create_app_structure' or 'create_ui_component' by focusing on database models, but lacks specificity on the model's purpose or scope.
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. It doesn't mention prerequisites, context (e.g., during app development), or exclusions. Sibling tools like 'create_app_structure' or 'create_plugin_structure' suggest related creation tasks, but no explicit comparison or usage scenarios are given.
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 the full burden of behavioral disclosure. It states 'create' which implies a write operation, but doesn't mention permissions required, side effects, error handling, or what happens upon success (e.g., if a file is generated or database updated). This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that states the action and resource. It's front-loaded with the core purpose, though it could be more structured by explicitly mentioning it's for Webasyst. No wasted words, but slightly under-specified for clarity.
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 tool that creates a payment plugin with 3 required parameters and no annotations or output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and what to expect after invocation, making it inadequate for safe and effective use by an AI agent.
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 description coverage is 100%, so the input schema already documents all three parameters (plugin_name, plugin_title, webasyst_path) with descriptions. The description adds no additional meaning beyond implying the plugin is for payments and located under 'wa-plugins/payment/', which is minimal value. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать плагин оплаты (wa-plugins/payment/)' specifies the verb 'create' and resource 'payment plugin' with a path hint, making the purpose clear. However, it doesn't differentiate from sibling tools like create_shipping_plugin or create_shop_plugin, leaving the scope vague regarding what makes a payment plugin distinct.
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 like create_shipping_plugin or create_plugin_structure. The description implies usage for creating payment plugins but offers no context on prerequisites, dependencies, or exclusions, leaving the agent to infer based on tool names alone.
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 states the tool assembles an archive but doesn't disclose behavioral traits such as whether it modifies the project, requires specific permissions, handles errors, or what the output looks like. This is inadequate for a tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (a tool that likely creates archives with potential side effects), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavior, parameters, and expected outcomes, leaving significant gaps for an AI agent to understand and use it correctly.
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 mentions assembling an archive but doesn't explain the parameters 'project_path' (e.g., what format or constraints) or 'output' (e.g., optional path or default behavior). This adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Собрать архив проекта для публикации' (Assemble project archive for publication) clearly states the action (assemble) and resource (project archive), but it's vague about specifics like archive format or content. It doesn't differentiate from siblings like 'create_app_structure' or 'create_theme', which might involve similar packaging operations.
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. The description implies it's for preparing a release, but it doesn't specify prerequisites, exclusions, or recommend other tools for related tasks like 'analyze_project' or 'validate_ui_usage' that might be used before or after.
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 of behavioral disclosure. It only states the action ('get information') without details on permissions required, rate limits, error conditions, or what the output looks like (e.g., JSON structure, fields returned). For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple retrieval tool, with zero waste or redundancy.
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 complexity (a read operation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what information is returned, potential errors, or how it differs from sibling tools. For a tool in a server with many similar 'get' and 'list' tools, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions in Russian ('ID приложения' for app_id, 'ID плагина' for plugin_id). The tool description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить информацию о плагине' (Get plugin information) states a clear verb ('get') and resource ('plugin information'), but it's vague about what specific information is retrieved. It doesn't distinguish from sibling tools like 'get_app_info' or 'list_app_plugins', which could provide overlapping functionality. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_app_info' and 'list_app_plugins', there's no indication of whether this tool is for detailed plugin metadata, status checks, or other purposes. Usage is implied by the name but not explicitly defined.
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 of behavioral disclosure. It only states the action ('execute CLI command') without detailing execution context (e.g., environment, permissions), potential side effects (e.g., system changes), error handling, or output format. This is inadequate for a tool that likely performs system operations.
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, clear sentence in Russian that directly states the tool's function without unnecessary words. It's front-loaded and efficiently conveys the core purpose.
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 complexity of a CLI execution tool with no annotations and no output schema, the description is insufficient. It lacks critical details like execution environment, safety considerations, expected outputs, or error behaviors, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'command' and 'args' parameters. The description adds no additional meaning beyond what's in the schema (e.g., no examples, command syntax, or constraints), meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Выполнить CLI команду Webasyst' (Execute Webasyst CLI command), which clearly indicates it runs CLI commands. However, it's vague about what Webasyst CLI is and doesn't distinguish this tool from potential sibling CLI tools (none exist in the provided list, but the description doesn't clarify this uniqueness).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
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 full burden. It states the tool creates a new application but doesn't disclose any behavioral traits: no information about permissions required, whether this is a destructive operation, what happens if an app already exists, rate limits, or what the output looks like. For a creation tool with zero annotation coverage, this is insufficient.
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 in Russian that directly states the tool's purpose. It's appropriately sized and front-loaded with no wasted words, making it easy to parse quickly.
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 complexity (5 parameters, 3 required, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral aspects, or what to expect after creation. For a tool that creates applications in a development environment, more context about prerequisites, side effects, and output is needed.
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 mentions 'в указанном пути' ('in the specified path'), which hints at the 'webasyst_path' parameter, but doesn't explain the other 4 parameters (name, title, description, features) or their purposes. The description adds minimal value beyond what the bare schema provides.
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 action ('Создать' = 'Create') and resource ('новое приложение Webasyst' = 'new Webasyst application'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this from sibling tools like 'create_app_structure' or 'create_plugin_structure', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools starting with 'create_' (like create_app_structure, create_plugin_structure, create_theme), there's no indication of what distinguishes this generic app creation from more specific creation tools.
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 of behavioral disclosure. While 'Создать' implies a write operation, the description doesn't specify permissions required, whether the creation is idempotent, what happens on conflicts (e.g., duplicate theme names), or any rate limits. For a creation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
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 complexity (5 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what a 'Shop-Script theme' entails, how parameters interact, what the creation process involves, or what to expect upon success/failure. For a creation tool with undocumented parameters and no structured guidance, this leaves critical 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 schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description adds no information about what parameters like 'theme_name', 'style_type', or 'color_scheme' mean, their formats, or how they affect the theme creation. With low schema coverage, the description fails to compensate by explaining parameter semantics.
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 action ('Создать' meaning 'Create') and the resource ('тему Shop-Script' meaning 'Shop-Script theme'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'create_theme' or 'create_site_theme', which appear to be similar theme creation tools for different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison with sibling tools like 'create_theme' or 'create_site_theme', leaving the agent with no usage differentiation.
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 of behavioral disclosure. While 'Создать' implies a write/mutation operation, the description doesn't address permissions needed, whether the operation is idempotent, what happens on failure, or what the response looks like. For a creation tool with 8 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information about what the tool does.
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 creation tool with 8 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It states what the tool does at a high level but provides no guidance on usage, no parameter explanations, and no behavioral context. The description doesn't compensate for the missing structured documentation.
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?
With 0% schema description coverage and 8 parameters (3 required), the description provides no information about any parameters. It doesn't explain what 'plugin_type', 'plugin_name', 'webasyst_path', or any other parameters mean or how they should be used. The description fails to compensate for the complete lack of schema documentation.
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 action ('Создать' meaning 'Create') and the resource ('плагин для приложения Site' meaning 'plugin for the Site application'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'create_plugin_structure' or 'create_payment_plugin', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools involving creation operations (create_action, create_plugin_structure, create_payment_plugin, etc.), there's no indication of when this specific site plugin creation tool is appropriate versus other creation tools.
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 for behavioral disclosure. It implies a setup or configuration action ('Подключить'), suggesting potential system changes, but doesn't specify if this is destructive, requires permissions, affects existing files, or has side effects. For a tool with 5 parameters and no annotation coverage, this is a significant gap in 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, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavior, parameter usage, output expectations, and differentiation from siblings. For a setup tool with multiple inputs, this minimal description doesn't provide enough context for effective agent use.
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 by explaining parameters. It adds no meaning beyond the schema, failing to clarify what 'project_type' entails, what 'target_path' expects, or the purpose of boolean flags like 'include_icons'. With 5 undocumented parameters, this is inadequate.
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 action ('Подключить' meaning 'Connect/enable') and the resource ('дизайн-систему Webasyst UI 2.0' meaning 'Webasyst UI 2.0 design system'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_ui_component' or 'validate_ui_usage', which could involve similar UI-related operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., during project setup or UI enhancement), or compare to siblings like 'create_theme' or 'generate_color_scheme'. This lack of usage context leaves the agent with minimal direction.
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 of behavioral disclosure. It only states the action ('get') without mentioning whether this requires permissions, what format the configuration is returned in, or if it's a read-only operation (though implied by 'get'). For a tool with zero annotation coverage, this lacks critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the purpose. It's appropriately sized for a no-parameter tool, with no wasted words, though it could be slightly more specific to improve clarity without losing 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?
Given the tool has no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what 'system configuration' entails, the return format, or any behavioral traits (e.g., read-only nature, potential errors). For a tool in a context with many sibling tools, more detail is needed to ensure proper usage.
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 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to compensate for any parameter gaps, so it meets the baseline expectation. No additional parameter semantics are required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить системную конфигурацию' (Get system configuration) clearly states the verb ('get') and resource ('system configuration'), but it's vague about what specific configuration is retrieved. It doesn't distinguish this tool from potential siblings like 'get_app_info' or 'get_plugin_info', which might also retrieve configuration data.
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. With siblings like 'get_app_info' and 'get_plugin_info' that might retrieve related configuration data, the description offers no context about scope (e.g., system-wide vs. app-specific) or prerequisites for usage.
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 of behavioral disclosure. It states it creates a plugin structure, implying a write operation, but lacks details on permissions, side effects, or response format. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Russian that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core function.
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 complexity of creating a plugin structure (a write operation), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like what 'structure' entails, success criteria, or error handling, leaving significant gaps for an AI agent.
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 description coverage is 100%, with all three parameters (app_id, plugin_id, plugin_name) documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Создать' - create) and the resource ('структуру нового плагина' - structure of a new plugin), making the purpose evident. However, it doesn't differentiate from sibling tools like 'create_site_plugin' or 'create_payment_plugin', which also create plugins, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools involving plugin creation (e.g., create_site_plugin, create_payment_plugin), there is no indication of context, prerequisites, or exclusions for this specific tool.
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. While 'create' implies a write operation, the description doesn't disclose important behavioral traits like what permissions are required, whether this is a one-time setup or can be modified later, what happens if layouts already exist, or any rate limits. The mention of isMobile() hints at conditional logic but doesn't explain implementation 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 a single, efficient sentence that gets straight to the point. It's appropriately sized for the tool's apparent complexity, though it could be slightly more informative given the lack of annotations and output schema.
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 no annotations, no output schema, and a creation tool with potential side effects, the description is insufficient. It doesn't explain what the tool returns, what the created layouts look like, how they integrate with the app, or any dependencies. For a tool that presumably modifies application structure, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with their types, defaults, and descriptions. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without adding value.
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 verb 'create' and the resource 'responsive layouts (Desktop + Mobile)', specifying that it creates layouts for both desktop and mobile with isMobile() functionality. However, it doesn't differentiate from sibling tools like create_app_structure, create_ui_component, or create_widget that might also create UI elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating UI components, themes, and structures, there's no indication of what makes this tool distinct or when it should be preferred over similar creation tools.
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 the full burden of behavioral disclosure. It states the action is to create a shipping plugin but doesn't mention whether this is a destructive operation, what permissions are required, if it modifies existing files, or what the expected outcome looks like. For a creation tool with zero annotation coverage, this leaves 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 a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every element (action, resource, path) contributing essential information.
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 complexity of creating a plugin (a mutation operation), no annotations, and no output schema, the description is insufficient. It lacks details on behavioral aspects like side effects, error conditions, or return values, which are critical for an agent to use this tool effectively in a development context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (plugin_name, plugin_title, webasyst_path) with descriptions in Russian. The description doesn't add any additional meaning or context about these parameters beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Создать' - create) and resource ('плагин доставки' - shipping plugin) with a specific directory path ('wa-plugins/shipping/'), making the purpose unambiguous. It distinguishes from siblings like create_payment_plugin or create_shop_plugin by specifying the shipping plugin type, though it doesn't explicitly contrast them.
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 like create_plugin_structure or create_generic_app. The description implies usage for creating shipping plugins but offers no context about prerequisites, dependencies, or scenarios where other tools might be more appropriate.
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 of behavioral disclosure. It states the tool creates a theme, implying a write operation, but doesn't disclose any behavioral traits such as permissions required, whether it's idempotent, what happens on conflicts, or error handling. This is a significant gap for a creation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 is a creation operation with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., what the tool returns, error conditions) and doesn't compensate for the absence of structured fields. For a tool with 4 parameters and mutation behavior, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 action (create) and resource (theme for an application) in Russian, which translates to 'Create a design theme for the application'. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'create_shop_theme' or 'create_site_theme' beyond the general context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other theme creation tools (e.g., 'create_shop_theme', 'create_site_theme') or related tools like 'generate_color_scheme'. There's no mention of prerequisites, context, or exclusions, leaving usage ambiguous.
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 for behavioral disclosure but provides minimal information. It states 'create' which implies a write/mutation operation, but doesn't disclose important behavioral aspects like whether this creates files on disk, what permissions are needed, whether it overwrites existing components, or what the expected output/result looks like. The description is too brief to adequately inform the agent about the tool's 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 extremely concise - a single phrase that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it efficient for quick understanding despite its brevity.
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 tool that creates UI components with 4 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what 'generating a UI component' actually means in practice - whether it creates template files, generates code, modifies configuration, or produces some other output. The agent needs more context about what this creation operation entails and what results to expect.
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?
With 100% schema description coverage, the baseline is 3. The description adds no additional parameter information beyond what's already documented in the schema. The schema already provides detailed descriptions for all 4 parameters including the enum values for component_type, format requirements for component_name, and conditional behavior for with_js.
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 action ('Сгенерировать' - Generate/Create) and the resource ('UI-компонент Webasyst 2.0'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_widget' or 'create_site_widget', which might create confusion about when to use this specific tool versus other UI creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that create UI elements (create_widget, create_site_widget, create_site_block), there's no indication of what distinguishes this UI component creation from those other tools or when this specific tool should be selected.
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 for behavioral disclosure. It states this is a creation operation but provides no information about permissions required, whether this is a destructive operation, what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this represents a significant gap in behavioral 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 extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized and front-loaded with the essential information.
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 creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what the return value might be, or any important behavioral context. The combination of being a mutation tool (creation) with no safety/behavioral annotations and no output schema requires more comprehensive description than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all 4 parameters documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 action ('Создать' - Create) and the resource ('виджет для Dashboard' - widget for Dashboard), providing specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'create_site_widget' or 'create_ui_component', which would require explicit differentiation for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple similar creation tools in the sibling list (create_site_widget, create_ui_component, etc.), but no indication of when this specific dashboard widget creation tool is appropriate versus those other options.
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 of behavioral disclosure. It states 'generate' but doesn't clarify if this creates new resources, modifies existing ones, requires specific permissions, or has side effects like overwriting data. For a tool with 7 parameters and no annotation coverage, this is a significant gap in 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, efficient sentence in Russian that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 has 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like whether it's a read or write operation, what the output looks like (e.g., CSS code or a configuration object), or error conditions. For a tool of this complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters with descriptions. The description adds no additional meaning beyond the schema, such as explaining relationships between colors or format requirements. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generate') and the resource ('CSS color scheme variables'), which is specific and understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_theme' or 'create_site_theme', which might have overlapping functionality in theme/color scheme creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given sibling tools like 'create_theme' and 'create_site_theme', there's no indication of whether this is for initial creation, updates, or a specific context like app-specific schemes versus site-wide themes.
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 of behavioral disclosure. It only states the basic action of retrieving app information without detailing aspects like authentication requirements, rate limits, error handling, or the format of the returned data. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple retrieval tool, earning its place with zero waste.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned, potential errors, or behavioral traits. For a tool with no structured data beyond the input schema, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'app_id' clearly documented as 'ID приложения'. The description adds no additional parameter information beyond what the schema provides, such as examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить информацию о конкретном приложении' clearly states the action (get/retrieve) and resource (app information) in Russian, making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_plugin_info' or 'list_webasyst_apps', which also retrieve information about apps or plugins, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_plugin_info' or 'list_webasyst_apps'. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on the name alone.
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 of behavioral disclosure. It states the action ('get') but doesn't describe what 'routing configuration' entails, whether it's read-only or has side effects, any permissions required, or the format of the returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy to parse quickly.
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 complexity of a configuration retrieval tool with no annotations, no output schema, and 1 parameter, the description is incomplete. It doesn't explain what 'routing configuration' includes, how it relates to the optional 'app_id', or what the return values look like. For a tool that likely returns structured data, more context is needed to be fully helpful.
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 1 parameter with 100% description coverage, documenting 'app_id' as optional. The description adds no parameter-specific information beyond what the schema provides. With 0 parameters effectively covered by the description, the baseline is 4, as the schema fully handles parameter documentation without need for compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить конфигурацию маршрутизации' (Get routing configuration) states a clear verb ('получить' - get) and resource ('конфигурацию маршрутизации' - routing configuration), establishing the basic purpose. However, it doesn't differentiate from sibling tools like 'get_app_info', 'get_plugin_info', or 'get_system_config', which also retrieve configuration data, leaving ambiguity about what specifically distinguishes this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_app_info' and 'get_system_config' that might retrieve related configuration data, there's no indication of context, prerequisites, or exclusions. Usage is implied only by the tool name and description, lacking explicit direction.
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 the full burden of behavioral disclosure. It only states the action without details on permissions, rate limits, output format, or pagination. For a read operation, this is insufficient as it lacks critical context for safe and effective use.
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 in Russian that directly states the tool's purpose without unnecessary words. It's front-loaded and efficient, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the list output looks like, any limitations, or behavioral traits, which are essential for a tool with no structured output documentation.
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 description coverage is 100%, with the parameter 'app_id' fully documented in the schema. The description doesn't add any extra meaning or context about the parameter beyond what's in the schema, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить список плагинов приложения' clearly states the action ('получить список' - get list) and resource ('плагинов приложения' - application plugins), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_app_themes' or 'list_app_widgets' beyond the resource type, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for a specific app or general listing. This leaves the agent without usage direction.
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 full burden. While 'Получить список' implies a read-only operation, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, pagination behavior, or what happens when the app_id doesn't exist. For a tool with zero annotation coverage, this is inadequate.
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 in Russian that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 tool with no annotations, no output schema, and multiple sibling creation tools, the description is insufficient. It doesn't explain what format the list returns, whether it includes all themes or just active ones, or how this read operation relates to the various theme creation tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'app_id' clearly documented as 'ID приложения'. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Получить список' meaning 'Get list') and resource ('тем оформления приложения' meaning 'application themes'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'create_theme' or 'create_site_theme', which would require explicit comparison for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'create_theme', 'create_site_theme', and 'generate_color_scheme', there's no indication of when this read operation is appropriate versus those creation/generation tools.
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 for behavioral disclosure. It states this is a read operation ('получить список'), but doesn't mention any behavioral aspects like pagination, rate limits, authentication requirements, or what happens if the app_id doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 read-only listing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the widget list returns, whether it's paginated, what fields are included, or any error conditions. The minimal description leaves too many questions unanswered for effective tool usage.
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 doesn't mention any parameters. However, with 100% schema description coverage (the single parameter 'app_id' has a clear description in the schema), the baseline is 3. The description adds no additional parameter context beyond what's already documented in the structured 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 states the action ('получить список' - get list) and resource ('виджетов приложения' - app widgets), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'list_app_plugins' or 'list_app_themes', but the resource specificity is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are related sibling tools like 'list_app_plugins' and 'list_app_themes' for similar listing operations, but no indication of when to choose widgets over plugins or themes, or any prerequisites for usage.
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 but only states the basic action. It doesn't disclose whether this is a read-only operation, if it requires authentication, what format the list returns, or any pagination/rate limiting considerations. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Russian that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 tool with no annotations and no output schema, the description is too minimal. It doesn't explain what the output looks like (array of app objects? just names?), doesn't mention authentication requirements, and provides no context about Webasyst ecosystem. Given the complexity of the sibling tools (many creation/management tools), this listing tool should provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'include_system'. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 when schema coverage is complete.
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 verb ('Получить список' - Get list) and resource ('всех приложений Webasyst' - all Webasyst applications), making the purpose unambiguous. It doesn't explicitly differentiate from siblings like 'get_app_info' or 'list_app_plugins', but the scope 'all applications' provides some implicit distinction.
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 like 'get_app_info' (for specific app details) or 'list_app_plugins' (for plugins within apps). The description only states what it does, not when it's appropriate compared to sibling tools.
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 of behavioral disclosure. It mentions what the tool checks (hardcoded colors, outdated patterns) and that it can show fix suggestions, but lacks critical details: whether it's read-only or makes changes, what permissions are needed, how results are returned (e.g., report format), or any rate limits. For a validation tool with zero annotation coverage, this leaves 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 a single, efficient sentence in Russian that directly states the tool's purpose and key checks. It's front-loaded with the main action ('Проверить' - Check) and includes no redundant information, making it appropriately concise and well-structured for quick understanding.
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 complexity (validation with multiple boolean toggles), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a report, success/failure status), how errors are handled, or behavioral traits like idempotency. For a tool with 4 parameters and no structured output, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (project_path, check_colors, check_components, fix_suggestions). The description adds minimal value beyond the schema—it mentions 'хардкод цветов' (hardcoded colors) and 'устаревшие паттерны' (outdated patterns), which align with check_colors and check_components, but doesn't provide additional context like parameter interactions or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Проверить использование UI 2.0' (Check UI 2.0 usage) with specific checks for hardcoded colors and outdated patterns. It uses a specific verb ('Проверить' - Check) and resource ('использование UI 2.0' - UI 2.0 usage), making the purpose clear. However, it doesn't explicitly distinguish itself from similar-sounding siblings like 'check_project_compliance' or 'analyze_project', which might also involve validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage. Given the many sibling tools (e.g., 'check_project_compliance', 'analyze_project'), there's no indication of how this tool differs or when it should be preferred, leaving the agent without usage direction.
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:

[![webasyst-mcp MCP server](https://glama.ai/mcp/servers/emmy-design/webasyst-mcp/badges/card.svg)](https://glama.ai/mcp/servers/emmy-design/webasyst-mcp)

Score Badge

Copy to your README.md:

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

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