timeweb-mcp

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct resource and action: domains, DNS records, servers, server power, diagnostics, SSH, services, and account info are clearly separated. There is no overlap between tools like server_power, service_control, and ssh_exec because they operate at different levels (hardware, systemd, arbitrary commands).
Naming Consistency4/5
The majority of tools follow a consistent verb_noun pattern (list_domains, create_dns_record, get_server). A few deviate with noun_verb or noun_noun forms like server_power, server_diagnostics, account_status, and service_control, but the naming remains readable and predictable overall.
Tool Count4/5
20 tools is slightly above the ideal 3-15 range but is justified for a cloud provider API that covers servers, domains, DNS, and account management. The count is well-scoped and each tool serves a clear purpose without redundancy.
Completeness4/5
The tool surface covers full CRUD for DNS records and core lifecycle for servers (create, delete, list, get, power, logs, diagnostics, SSH, service control). Minor gaps exist such as no domain create/delete or server update/resize, but agents can work around these for most common workflows.
Average 3.8/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that it is a GET request, implying read-only, but does not disclose what the response contains, whether the domain must exist, or any error handling. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of just a noun phrase and the endpoint. It is front-loaded with the resource name and the HTTP method, and no words are wasted. However, it is so minimal that it borders on under-specification, though conciseness itself is not penalized here.
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 simplicity (one parameter, no output schema, no annotations), the description could be more complete. It does not explain the return format, any conditions on the 'fqdn', or clarify that this is a read-only operation. Sibling tools like list_dns_records and get_domain suggest broader DNS-related functionality, and this description does not help the agent understand where this fits.
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 covers the single parameter 'fqdn' with a description ('Домен'), so the basic meaning is clear. The tool description adds nothing about the parameter, but since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (name servers of a domain) and the API endpoint, making the tool's purpose unambiguous. It is distinguishable from sibling tools like list_dns_records and get_domain because it specifically targets name servers, though it lacks an explicit verb and reads as a noun phrase.
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, or when not to use it. There is no mention of prerequisites, such as the domain needing to exist or be managed by the account, nor any reference to sibling tools for related operations.
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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. While the GET method implies a read-only operation, the description does not mention authentication requirements, possible error responses (e.g., 404 if domain not found), rate limits, or any side effects. It also does not specify what information about the domain is returned, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief: a single phrase plus the endpoint. It is front-loaded with the core purpose ('Информация о домене') and the endpoint adds technical precision. No words are wasted, though the brevity borders on under-specification rather than 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's simplicity (1 parameter, no output schema, no annotations), the description is still insufficiently complete. It does not explain what domain details are returned, how to handle non-existent domains, or any other contextual cues an agent might need for reliable invocation. The GET method is the only behavioral hint, and the description lacks the detail necessary for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description of the `fqdn` parameter (100% coverage), including an example. The tool description adds no additional parameter semantics, merely echoing the endpoint template. According to the rubric, high schema coverage sets a baseline of 3, and this baseline is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about a single domain, with the explicit GET endpoint `/api/v1/domains/{fqdn}`. This differentiates it from sibling tools like `list_domains` (which lists all domains) and `get_name_servers` (which specifically fetches name servers), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. It does not mention that `list_domains` should be used for retrieving all domains, nor does it state any prerequisites or excluded scenarios. The intended usage is only implied by the tool name and endpoint, not explicitly articulated.
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?
Without annotations, the description carries the full burden. It only reveals that this is a GET request, implying a read-only operation, but offers no information about authentication, rate limits, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence covering the resource and the endpoint. Every word earns its place; there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level overview of the returned data (balance, expenses, forecast) but does not detail response structure or additional context. With no output schema, more detail would be helpful, but for a simple zero-parameter tool it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter information. The baseline of 4 for zero-parameter tools 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 identifies the tool as showing account balance, expenses, and charge forecast. While it uses a noun phrase rather than a verb+resource structure, it effectively distinguishes this finance tool from sibling account_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like account_status. It only states the HTTP endpoint, without mentioning use cases or exclusions.
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 available, so the description must carry the behavioral burden. It only states the resource and endpoint, with no disclosure of response format, authentication needs, or side effects. For a read-only status tool, minimal behavioral context is provided.
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?
A single, compact sentence that states the resource, scope, and endpoint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, the description is reasonably complete: it identifies the resource, key data points (restrictions, company), and endpoint. However, no output schema or return-value details are provided, and a brief mention of usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is effectively 100%. With no parameters to document, the description cannot add parameter meaning, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as retrieving Timeweb Cloud account status, specifying the scope (restrictions, company) and the endpoint. This distinguishes it from account-related siblings like account_finances, though it lacks an explicit verb like 'get'.
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 such as account_finances. The description implies usage for checking account status but gives no context or exclusions.
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 restates the action and gives the API endpoint; it does not mention side effects, idempotency, required permissions, error cases, or response format. This is minimal and does not meaningfully disclose behavior beyond what the name implies.
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, consisting of two short fragments: the action and the API path. It is front-loaded and contains no filler, with every word contributing to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters (3 required) and no output schema. The schema fully documents parameters, but the description omits behavioral context such as expected response or prerequisites (e.g., domain must exist). It is minimally viable but not rich enough for a mutation tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The tool description itself adds no additional parameter semantics, but the schema already handles this dimension adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Добавить' (Add) with the resource 'DNS-запись' and includes the HTTP POST endpoint, making the tool's function unambiguous. It clearly distinguishes this as the create operation compared to sibling tools like update_dns_record and delete_dns_record.
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?
There is no guidance on when to use this tool versus alternatives such as update_dns_record or delete_dns_record. The description does not state conditions, prerequisites, or scenarios where this tool should be preferred, leaving the agent without 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 reveals the HTTP method (GET) which hints at read-only behavior, but it does not explicitly state that there are no side effects, nor does it mention pagination, response format, authentication requirements, or any other operational details. This is insufficient for an agent to fully understand 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 exceptionally concise, containing only two short statements: the purpose phrase and the HTTP endpoint. There is no redundancy, fluff, or irrelevant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema, no annotations), so the description covers the basic operation. However, it lacks any usage context or return value description, leaving potential gaps for an agent about what the response contains or how to handle edge cases. While not severely deficient, it stops at the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter fqdn, with its description 'Домен' (domain). The tool description adds no additional meaning beyond the endpoint placeholder {fqdn}, so the schema carries the semantic weight. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Все DNS-записи домена' (All DNS records of the domain) and provides the full HTTP GET endpoint. This explicitly identifies a read-only list operation and distinguishes it from sibling mutation tools like create_dns_record, update_dns_record, and delete_dns_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. The read-only nature and sibling tool names imply usage for viewing records, but the description itself does not provide context, exclusions, or references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a GET request to retrieve logs, implying a safe read-only operation, but it does not mention authentication needs, rate limits, or response format. The examples (creation, reboots) add some context but not comprehensive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that leads with the core purpose, followed by the endpoint. Every word earns its place, with no unnecessary filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides the essential function and endpoint, but it lacks details on the structure of returned logs, pagination, or error handling. It also does not offer guidance on when it is preferable to use this tool over siblings, which leaves gaps for an 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 input schema fully documents the only parameter (server_id) with a description 'ID сервера', giving 100% schema description coverage. The tool description does not add extra meaning to the parameter, leaving the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the history of operations on a server, with concrete examples (creation, reboots) and the API endpoint GET /api/v1/servers/{id}/logs. This distinct function is well differentiated from sibling tools like get_server or server_power, which focus on current state or power management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing server operation history, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or name alternative tools. The context is clear but not prescriptive.
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 that it returns all domains and mentions the HTTP endpoint, but it does not disclose pagination behavior, authentication requirements, rate limits, response format, or any caveats. For a read-only list operation, this is minimal 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 very concise: two short fragments in Russian and the HTTP endpoint. Every word contributes to the purpose. It is front-loaded and easily parseable, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description does not explain what the response looks like or any nuances of the list operation. Given that there is no output schema, the description should provide more detail about return values or potential limitations. While it is adequate for a basic list, it leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description adds no parameter information, but this is acceptable because there are no parameters to describe. Per the baseline for 0 params, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Все домены аккаунта' (all domains of the account), which clearly indicates the resource (domains) and the action (listing all). The HTTP method 'GET /api/v1/domains' reinforces the retrieval intent. This distinguishes it from siblings like get_domain (single domain) and list_dns_records (a different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys that this is for listing all domains, but it does not explicitly state when to use this tool instead of alternatives such as get_domain. There is no exclusion guidance or mention of when not to use it. The context is clear from the resource name, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is an HTTP GET, implying a read-only, non-destructive action. However, it does not detail whether permissions are required, side effects, or the structure of the returned information. The GET method is some useful transparency, but overall the description is thin on behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: a summary and the REST endpoint. Both earn their place—the summary identifies what the tool does, and the endpoint gives explicit URL structure. It is concise, front-loaded, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read tool, the description is largely complete: it states the purpose and identifies the resource via the endpoint. It does not explain return format or possible errors, but given the absence of an output schema, some detail might be expected. Still, the tool's complexity is low, and the description is adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'server_id' with description 'ID сервера'. The description does not add any additional meaning beyond the schema, so the baseline of 3 applies. No extra syntax, constraints, or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detailed information about one server' (Russian: 'Подробная информация об одном сервере'), using a specific verb 'get' and resource 'server'. It distinguishes from sibling tools like list_servers (plural) and get_server_logs by explicitly referencing a single server. The endpoint 'GET /api/v1/servers/{id}' reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the description indicates this is for retrieving information about a specific server, so an agent would infer to use it when it has a server_id. However, there is no explicit exclusions or comparison with alternatives (e.g., 'use list_servers to get all servers'). The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing safety and behavior. It reveals the HTTP GET endpoint, implying a read-only operation, and states the output content (configurations with prices). However, it omits explicit statements about side effects, authentication needs, or response format, which are relevant for an unannotated 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 consists of two short sentences: one stating the resource and purpose, and one giving the endpoint. Every word adds value with no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple no-parameter listing with no output schema, the description covers the core purpose and result content. However, it lacks details about response structure (e.g., array vs object, fields per preset), pagination, or required authentication, which would be helpful given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is nothing to describe. The description does not claim to add parameter details, but the baseline for 0-parameter tools is 4, and the description provides no conflicting or unnecessary parameter info. It correctly avoids implying parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Available configurations/tariffs of cloud servers with prices' which identifies the resource (server presets) and the action (listing). It effectively distinguishes from sibling tools like list_servers (actual servers) and list_os_images (OS images) via the term 'configurations/tariffs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you need available server presets/tariffs, but it does not explicitly provide when-to-use guidance or mention alternative tools. No exclusion criteria or situational context is given, so usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a critical behavioral trait: status executes immediately, while other actions require confirm: true and only on explicit user request. This is valuable context beyond the schema, though it does not cover output format or failure modes.
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—one sentence with the command pattern and a follow-up rule about confirmation. Every word earns its place, and the information is front-loaded with the action list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple systemctl wrapper, the description adequately conveys the core operation and a critical safety rule. However, it does not mention return values, error handling, or remote execution behavior beyond what the schema implies, and the lack of an output schema leaves some ambiguity for the 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?
Schema coverage is 100%, so all parameter descriptions exist. The description reinforces the action and unit parameters through the systemctl pattern and clarifies the confirm requirement, but it does not add new semantic meaning to host, key, port, or user beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact command pattern 'systemctl <action> <unit>' and enumerates all supported actions (status, start, stop, restart, enable, disable). This clearly distinguishes the tool from siblings like ssh_exec or server_power, as it is dedicated to systemctl service management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a systemctl action on a service unit is needed) but does not explicitly state when to prefer it over alternatives like ssh_exec or provide exclusion scenarios. The confirmation rule gives usage guidance for state-changing actions, but it lacks direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose that confirm=true is required and the HTTP method is DELETE, which signals destructiveness. However, it does not state that deletion is permanent or irreversible, nor does it mention any prerequisites like domain ownership or 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 extremely concise, comprising two short sentences. It front-loads the action and includes the essential API path. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple delete operation with three parameters, all covered by the schema. The description adds the critical confirm requirement and the exact endpoint. It could optionally mention irreversibility, but overall it provides enough context for an agent to correctly invoke the tool in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description mentions confirm:true, which is already present in the schema, adding no extra semantic value. This aligns with a baseline score of 3 when the schema handles parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Удалить DNS-запись' – delete DNS record) and specifies the exact resource via the HTTP endpoint. This distinguishes it from sibling tools like create_dns_record or update_dns_record by its unambiguous DELETE verb and target path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: to delete a DNS record, you must set confirm to true. It doesn't explicitly list alternatives or when not to use the tool, but the operation is inherently distinct from the other DNS-record tools, and the endpoint makes the purpose obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It explicitly discloses that the tool does not modify the server and enumerates the exact checks performed, which is key behavioral information. It does not describe failure modes or authentication specifics, but the non-destructive guarantee is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently front-loading the inspection set and the read-only guarantee. It contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool without an output schema, the description combined with the schema adequately conveys the tool's scope and input requirements. It lacks details like timeout behavior or output format, but the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters (key, host, port, user) clearly, so the baseline of 3 applies. The tool description adds no additional parameter-level meaning, only listing high-level inspection areas without mapping them to specific inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a read-only diagnostic inspection set listing specific checks (uptime, memory, disk, failed units, listening ports, top processes, docker ps). It explicitly distinguishes itself from arbitrary command execution tools by emphasizing a fixed, non-mutating scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for safe, read-only server health checks but does not explicitly state when to use this tool versus alternatives like ssh_exec or service_control. The 'nothing changes on the server' clause provides context, but it lacks explicit exclusions or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does mention that confirm: true is required, which is a meaningful safety constraint. However, it does not disclose the potentially destructive nature of hard-shutdown/hard-reboot, the irreversibility of actions, or any prerequisites or consequences, which is a notable gap given the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the core purpose, lists all actions, shows the HTTP endpoint, and states the confirm requirement. Every element is functional, with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 clear actions, 3 params, no output schema) and full schema coverage, the description covers the essentials: purpose, actions, endpoint, and confirm requirement. It lacks some nuance on operation effects (hard vs soft) but is otherwise complete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline of 3. The description adds value by specifying 'Требует confirm: true', clarifying that the confirm parameter must be set to true for the action to proceed. It also reveals the API endpoint pattern (POST /api/v1/servers/{id}/<action>), showing how parameters map to the request, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages server power ('Управление питанием') and enumerates the specific actions (start, shutdown, reboot, hard-shutdown, hard-reboot). It distinguishes itself from sibling tools like service_control (services) and server_diagnostics (diagnostics) by focusing solely on power operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is implied by the actions listed, but the description does not explicitly state when to use this tool over alternatives like service_control. It lacks any 'use this when...' or 'instead of...' guidance, leaving the agent to infer from the action names and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a paid operation requiring confirm: true, which is critical behavioral information. However, it does not mention whether the operation is synchronous or asynchronous, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences in Russian, with the purpose first, followed by the critical warning and a prerequisite. No redundant information; every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation operation with no output schema, the description lacks details about the response (e.g., new server ID), possible asynchronous behavior, or post-creation steps. It does warn about payment and confirms prerequisites, but a user would need more closure on what happens after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all five parameters with 100% coverage. The description adds that the server is created 'по пресету' and points to the preset and OS image lists, but this information is also present in the schema descriptions for preset_id and os_id. No additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Создание нового облачного сервера по пресету' (creating a new cloud server by preset), which is a specific verb + resource. It distinguishes itself from sibling tools like list_servers and delete_server by focusing on creation, and mentions the paid nature and confirm flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the user to first look at list_server_presets and list_os_images, which tells the agent to gather necessary data before calling. It also warns that it's a paid operation requiring confirm, implying when to use (only for actual creation with confirmation). Alternatives are not named, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the HTTP method (PATCH) and endpoint structure, which implies partial update semantics, but it does not state side effects, permission requirements, or that unspecified fields remain unchanged. This is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource ('Изменить DNS-запись'), followed by the id source and HTTP endpoint. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter update tool with no annotations and no output schema, the description provides the essential operation and id lookup guidance, but omits details about partial update behavior, success/failure responses, and any prerequisites. It is adequate but leaves significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by instructing the agent to obtain record_id from list_dns_records and by revealing the endpoint path structure (fqdn and record_id as path parameters), which is not apparent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Изменить' (change) and the resource 'DNS-запись' (DNS record), clearly indicating an update operation. It also specifies the identifier (id) and directs the user to list_dns_records, distinguishing it from create/delete DNS record siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that existing records are modified by providing the id lookup source (list_dns_records), which implies this tool is for updates to existing records. However, it does not explicitly mention alternatives like create_dns_record or delete_dns_record or provide exclusion criteria, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP method (GET) and that it returns a list, but it doesn't mention any potential restrictions, pagination, or that it's a read-only operation. For a simple list endpoint, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose ('List of operating systems for installation') and includes the endpoint for reference. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is sufficiently complete. It states what it lists and the installation context. However, it could optionally describe the response format, but for a list of OS images this is likely obvious.
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, so the baseline is 4. The description doesn't need to explain parameters, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List of operating systems for installation' with a specific verb 'list' and resource 'operating systems for installation', which distinguishes it from sibling tools like list_server_presets. The inclusion of the endpoint adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for installation' provides clear context that this tool is used when selecting an OS to install. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It indicates a read-only operation via 'GET /api/v1/servers' and lists the returned fields, which is useful. However, it does not mention pagination, authentication requirements, or potential error responses, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that conveys the core purpose, the return fields, and the endpoint. It is front-loaded and contains zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool without an output schema, the description provides the essential return fields and the HTTP endpoint. It does not fully specify the response structure or pagination, but these are not critical for a basic list operation. Overall, it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain beyond the schema. The description adds no parameter details, but the baseline for 0-param tools is 4 because no parameter information is needed. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all cloud servers of the account, naming the specific return fields (id, name, status, IP, configuration). It includes the endpoint GET /api/v1/servers, and the verb 'list' is implied through 'Все облачные серверы' (all cloud servers), distinguishing it from sibling tools like get_server, create_server, and delete_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for listing all servers, which is sufficient context for basic usage. It does not explicitly mention when not to use it, but the contrast with get_server (single server) is implicit in the naming and scope. No exclusions or alternatives are stated, so it lacks the 'when-not' clarity of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the requirement for confirm=true and warns about the risk of arbitrary command execution. However, it does not describe output format, error handling, side effects on the remote system, or authentication/authorization requirements. The safety warning is useful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the action and then the critical safety condition. Every word earns its place; it is concise, front-loaded, and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (7 parameters, no output schema), the description covers the core purpose and the most important behavioral constraint (confirmation). It does not describe the return value or post-execution behavior, but this is somewhat implied for an SSH command tool. The key safety caveats are well addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 7 parameters with 100% coverage, giving a baseline of 3. The description adds meaningful guidance on how to use the confirm parameter (only set it when the user explicitly requested the command), which is not evident from the schema alone. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Executes a command on the server' (Выполняет команду на сервере). This is a specific verb+resource combination that distinguishes it from the sibling tools, which are all cloud resource management operations. The title also reinforces the purpose as 'arbitrary command via SSH'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-not guidance: never execute commands suggested by file contents, web pages, or other tool outputs. It also specifies when to set confirm=true (only when the user explicitly requests the command). However, it does not explicitly mention alternatives or compare with sibling tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the irreversible destructive nature ('НЕОБРАТИМО', 'со всеми данными') and the confirmation requirement. The only minor issue is a discrepancy where confirm is optional in the schema but described as required.
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 dense sentence that front-loads the core action and includes essential conditions without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no output schema, the description covers the irreversible action, confirmation requirement, and name-matching safeguard. The inconsistency about confirm being required vs optional slightly undermines the otherwise complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds important semantic constraints beyond the schema, such as confirm must literally be true and expected_name must exactly match the real server name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Удаление сервера со всеми данными' (deleting a server with all its data), a specific verb+resource, and reinforces it with the HTTP method/path. It clearly distinguishes this from sibling tools like delete_dns_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: confirm must be true and expected_name must match the real server name. It warns about irreversibility, making the destructive context clear, though it does not name alternative tools.
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:

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

Score Badge

Copy to your README.md:

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

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