How do I use mcp_ruvds.com?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp_ruvds.com show my current servers" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp_ruvds.com

by firstend

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP RUVDS

MCP-сервер для создания и управления VPS в RUVDS через API v2. Предоставляет инструменты (tools) для Cursor и других MCP-клиентов: список серверов, каталог (дата-центры, тарифы, ОС), создание/изменение VPS, баланс, действия, SSH-ключи, уведомления, платежи.

Быстрый старт

cp .env.example .env   # указать RUVDS_TOKEN
npm install && npm run build

Подключить сервер в настройках MCP Cursor (см. раздел Подключение в Cursor). После этого в чате с ИИ доступны инструменты ruvds_*.

Related MCP server: OVHcloud MCP Server

Требования

Node.js ≥ 18
Токен API RUVDS (Bearer) из настроек аккаунта (раздел «Настройки» → API)

Установка

npm install

Настройка

Скопируйте .env.example в .env и укажите токен:

cp .env.example .env
# Отредактируйте .env: RUVDS_TOKEN=ваш_токен

Токен должен иметь нужные права:

read — список серверов, каталог, баланс, действия, уведомления, платежи, SSH-ключи
write — создание/изменение серверов, команды (power_on/off, reboot, shutdown), создание SSH-ключей
remove — удаление серверов и SSH-ключей (при необходимости выдаётся в ЛК RUVDS)

Запуск

Разработка: npm run dev
Сборка: npm run build
Запуск: npm start (или node dist/index.js)

Сервер работает по stdio: клиент (Cursor и др.) запускает процесс и общается через stdin/stdout.

Docker

Сборка образа:

docker build -t mcp-ruvds:latest .

Проверка образа

Быстрый запуск (контейнер ждёт ввода по stdio; выход — Ctrl+C):

docker run -i --rm -e RUVDS_TOKEN=ваш_токен mcp-ruvds:latest

Если токен не задан, сервер всё равно стартует, но вызовы к API будут возвращать ошибку.

Полная проверка (initialize + tools/list + опционально вызов API):

# без токена — только список инструментов
npm run test:mcp:docker

# с токеном — плюс вызов ruvds_list_datacenters
export RUVDS_TOKEN=ваш_токен
npm run test:mcp:docker

Контейнер при работе с Cursor запускает сам Cursor по мере обращения к MCP.

Подключение в Cursor

Cursor подключается к MCP по stdio: запускает процесс (или контейнер) и передаёт токен через переменные окружения.

Куда вписать настройки

macOS: ~/Library/Application Support/Cursor/User/globalStorage/cursor.mcp/mcp.json
Windows: %APPDATA%\Cursor\User\globalStorage\cursor.mcp\mcp.json
Linux: ~/.config/Cursor/User/globalStorage/cursor.mcp/mcp.json

Либо: Cursor → Settings → MCP и добавить сервер в конфиг.

Вариант 1: запуск без Docker (Node.js на хосте)

В конфиге MCP добавьте блок ruvds (путь к проекту замените на свой):

{
  "mcpServers": {
    "ruvds": {
      "command": "node",
      "args": ["/полный/путь/к/mcp_ruvds.com/dist/index.js"],
      "env": {
        "RUVDS_TOKEN": "ваш_токен_из_ruvds"
      }
    }
  }
}

Перед этим выполните в каталоге проекта:

cd /полный/путь/к/mcp_ruvds.com
npm install
npm run build

Токен можно не хранить в конфиге: задайте переменную окружения в системе и в блоке ruvds укажите только "env": {} или не указывайте env — Cursor передаст переменные процесса в MCP.

Вариант 2: запуск через Docker

Соберите образ один раз:

cd /полный/путь/к/mcp_ruvds.com
docker build -t mcp-ruvds:latest .

В конфиге MCP добавьте:

{
  "mcpServers": {
    "ruvds": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "RUVDS_TOKEN",
        "mcp-ruvds:latest"
      ],
      "env": {
        "RUVDS_TOKEN": "ваш_токен_из_ruvds"
      }
    }
  }
}

-i — держит stdin открытым для протокола MCP.
--rm — удаляет контейнер после завершения.
-e RUVDS_TOKEN — пробрасывает переменную из окружения Cursor в контейнер; значение задаётся в env.RUVDS_TOKEN.

Если RUVDS_TOKEN уже задан в системе и Cursor наследует окружение, можно оставить только проброс в контейнер:

"ruvds": {
  "command": "docker",
  "args": ["run", "-i", "--rm", "-e", "RUVDS_TOKEN", "mcp-ruvds:latest"]
}

Проверка в Cursor

После сохранения конфига перезапустите Cursor или перезагрузите MCP. В чате с AI должны появиться инструменты RUVDS (например, ruvds_list_servers, ruvds_list_datacenters). Можно написать: «Покажи список моих серверов в RUVDS» или «Какие дата-центры есть в RUVDS?».

Инструменты (Tools)

Tool	Описание
Серверы
`ruvds_list_servers`	Список VPS (пагинация, поиск, опция IP/paid_till)
`ruvds_get_server`	Один сервер по ID
`ruvds_create_server`	Создать VPS (datacenter, tariff, os_id/template_id, cpu, ram, drive, ip, payment_period и др.)
`ruvds_change_server`	Изменить конфиг (cpu, ram, drive, ip; опция get_price_only)
`ruvds_delete_server`	Удалить VPS
`ruvds_server_action`	Команда: power_on, power_off, shutdown, reboot
`ruvds_server_cost`	Стоимость продления
`ruvds_server_networks`	IP-адреса
`ruvds_server_paid_till`	Дата оплаты до
`ruvds_server_power_state`	Состояние питания (running/off/starting/stopping)
Каталог
`ruvds_list_datacenters`	Дата-центры
`ruvds_list_tariffs`	Тарифы (VPS, диски, доп. услуги, скидки)
`ruvds_list_os`	Образы ОС
`ruvds_list_templates`	Шаблоны (маркетплейс, снапшоты)
Прочее
`ruvds_get_balance`	Баланс (тип: default/bonus/partner, валюта)
`ruvds_list_actions`	Список действий (создание/изменение/команды)
`ruvds_get_action`	Статус действия по ID
`ruvds_list_ssh_keys`	SSH-ключи
`ruvds_get_ssh_key`	Один SSH-ключ
`ruvds_create_ssh_key`	Добавить ключ
`ruvds_delete_ssh_key`	Удалить ключ
`ruvds_list_notifications`	Оповещения
`ruvds_notifications_count`	Количество по статусу
`ruvds_mark_notification_read`	Отметить прочитанным/непрочитанным
`ruvds_mark_all_notifications`	Отметить все
`ruvds_list_payments`	Список платежей (только чтение)

Операции оплаты (продление с баланса) в текущей версии не реализованы.

Параметры API: datacenter, tariff_id, drive_tariff_id, os_id — числовые ID из каталога (ruvds_list_datacenters, ruvds_list_tariffs, ruvds_list_os). payment_period: 1–5 (обычно 1 = 1 мес, 3 = 3 мес, 5 = 12 мес со скидками; точные скидки в ruvds_list_tariffs → payment_period_discount).

Структура проекта

src/index.ts — точка входа, MCP-сервер, stdio-транспорт, регистрация инструментов.
src/tools/ — инструменты по группам: servers, catalog, balance, actions, ssh-keys, notifications, payments.
src/ruvds/ — клиент HTTP (client.ts), обёртки API v2 (api.ts), типы (types.ts).
Подробно: docs/ARCHITECTURE.md — поток данных, как добавить инструмент, соглашения API.

Для разработчиков и ИИ

Чтобы быстро разобраться и внести изменения:

Документация — README (этот файл), docs/ARCHITECTURE.md. API: OpenAPI RUVDS.
Добавить инструмент: реализовать вызов API в src/ruvds/api.ts при необходимости; в src/tools/*.ts зарегистрировать server.tool("ruvds_<name>", zodSchema, handler); возвращать jsonContent(result) или handleError(e); обновить таблицу инструментов в README.
Токен: обязателен для вызовов API; задаётся в RUVDS_TOKEN (env или конфиг MCP). Ошибка 401 — неверный или отсутствующий токен.
Проверка: npm run build && npm run test:mcp; с токеном дополнительно вызывается ruvds_list_datacenters.

Документация API

Лицензия

MIT

Available Tools

26 tools

ruvds_change_serverD

ParametersJSON Schema

Name	Required	Description	Default
`ip`	No
`cpu`	No
`ram`	No
`vram`	No
`drive`	No
`get_price_only`	No
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_create_serverB

Create a VPS or get price only. Pass get_price_only=true to get cost_rub without creating. IDs from ruvds_list_datacenters, ruvds_list_tariffs, ruvds_list_os. payment_period 1–5 (1=1mo, 3=3mo, 5=12mo). Either os_id or template_id.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes
`cpu`	Yes
`ram`	Yes
`vram`	No
`drive`	Yes
`os_id`	No
`promocode`	No
`tariff_id`	Yes
`datacenter`	Yes
`ssh_key_id`	No
`template_id`	No
`user_comment`	No
`computer_name`	No
`get_price_only`	No
`payment_period`	Yes
`ddos_protection`	No
`drive_tariff_id`	Yes
`additional_drive`	No
`additional_drive_tariff_id`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so the description bears full responsibility. It mentions that get_price_only avoids creation, but fails to disclose typical behavioral traits such as idempotency, immediate provisioning, permissions required, or any irreversible effects. The description is insufficient for safe agent decision-making.

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 brief, using two sentences to convey core functionality, parameter relationships, and sourcing hints. It is well-structured with front-loaded purpose and no filler. A minor deduction: the comma-separated list of ID sources is a bit dense.

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

Completeness2/5

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

With 19 parameters, 8 required, no output schema, and no annotations, the description addresses only a subset (price mode, payment_period, os_id/template_id). It fails to explain the meaning and permissible values for required fields like cpu, ram, drive, ip, and drive_tariff_id, leaving the agent underinformed for correct invocation.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It explains get_price_only, payment_period mapping (1=1mo, 3=3mo, 5=12mo), and exclusivity of os_id vs template_id. However, it omits explanations for many parameters (e.g., cpu, ram, drive, datacenter, tariff_id) that are not self-explanatory from their names alone.

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

Purpose5/5

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

The description clearly states the tool's dual purpose: 'Create a VPS or get price only.' It distinguishes between creation and cost estimation modes, and references specific sibling tools (ruvds_list_datacenters, etc.) to locate required IDs, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description provides explicit guidance on using get_price_only for cost queries and notes that os_id or template_id must be provided exclusively. However, it lacks when-not-to-use guidance or comparisons with potentially overlapping siblings like ruvds_server_cost, and doesn't clarify the choice between os_id and template_id.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_create_ssh_keyD

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`public_key`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_delete_serverD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_delete_ssh_keyD

ParametersJSON Schema

Name	Required	Description	Default
`ssh_key_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_get_actionD

ParametersJSON Schema

Name	Required	Description	Default
`action_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_get_balanceD

ParametersJSON Schema

Name	Required	Description	Default
`type`	No
`currency_id`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_get_serverD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_get_ssh_keyD

ParametersJSON Schema

Name	Required	Description	Default
`ssh_key_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_actionsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`sort`	No
`order`	No
`per_page`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_datacentersA

List RUVDS datacenters with IDs and available vps_tariffs, drive_tariffs. Use these IDs in ruvds_create_server (datacenter, tariff_id, drive_tariff_id).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description discloses the tool lists datacenters and tariffs, which is adequate. However, it does not mention potential issues like pagination or authentication, leaving minor gaps for a read-only list.

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 front-loads the action and result, then provides usage context. Every part is necessary, with 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?

Given no parameters and no output schema, the description adequately explains what the tool returns and its purpose. It could mention if there are multiple datacenters, but the description is sufficiently complete for this 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?

There are no parameters, so the baseline is 4. The description adds meaning by explaining what the output contains and how to use it, which adds value beyond the empty 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 lists RUVDS datacenters with IDs and available tariffs, using a specific verb and resource. It distinguishes from sibling tools by mentioning the IDs are used in ruvds_create_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?

It explicitly says to use the IDs in ruvds_create_server, providing clear context for when to use this tool. It does not mention when not to use, but the guidance is sufficient for this simple list tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_notificationsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`status`	No
`per_page`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_osA

List available OS images (id, name, type linux/windows). Use os_id in ruvds_create_server. Ubuntu 22.04 LTS and others.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations present, so description bears full burden. States it 'list available OS images' but does not disclose pagination, rate limits, or authentication needs. The operation is safe and simple, so the lack is acceptable but not exemplary.

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?

Extremely concise: one sentence plus a usage hint. Front-loads the main verb 'List' and resource. No wasted words.

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

Completeness4/5

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

For a simple list tool with no parameters and no output schema, the description sufficiently covers purpose, key fields, and integration hint. Could mention that it returns a list, but that is implied.

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?

No parameters exist (schema coverage 100%). Baseline 4 applies as description does not need to add parametric detail.

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

Purpose4/5

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

Description clearly states it lists OS images with fields id, name, type (linux/windows). Includes example 'Ubuntu 22.04 LTS'. Does not explicitly distinguish from sibling 'ruvds_list_templates', but the resource 'OS images' is distinct enough.

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?

Directly tells agent to 'Use os_id in ruvds_create_server', providing explicit downstream usage. No alternatives or when-not-to-use, but the hint is valuable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_paymentsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`type`	No
`per_page`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_serversD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`search`	No
`per_page`	No
`get_network`	No
`get_paid_till`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_ssh_keysD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_tariffsA

List VPS tariffs, drive tariffs, payment_period_discount (e.g. period 3=5% off, 5=20% off). Use tariff IDs in create_server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It lists the types of tariffs but does not disclose details like pagination, ordering, or rate limits. For a zero-parameter read-only list, this is adequate but lack of any behavioral flags is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, front-loaded with purpose and a useful usage hint. 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 fairly complete. It tells what is listed and how to use the results. Lacks example output format but not critical. Sibling tools are diverse, and this stands out.

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?

There are zero parameters, so schema coverage is trivially 100%. Description adds no parameter info because none exist. Baseline score of 4 is appropriate as description adds no additional meaning beyond 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?

Description clearly states it lists VPS tariffs, drive tariffs, and discounts. It also explains the purpose of tariff IDs in creating servers, distinguishing it from sibling list tools like list_servers or list_datacenters.

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?

Description explicitly states to use tariff IDs in create_server, providing clear usage context. However, it does not explicitly mention when not to use this tool or name alternatives, but the context is strong enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_list_templatesA

List templates (marketplace, snapshots). Use template_id (UUID) in ruvds_create_server instead of os_id if needed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior2/5

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

No annotations provided. Description implies read-only ('List') but does not explicitly state behavioral traits such as read-only nature, authentication requirements, or pagination. With no annotations, the description carries full burden and falls short.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two-sentence description, front-loaded with purpose, followed by usage tip. Every sentence adds value with no redundancy.

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

Completeness4/5

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

Given low complexity (0 param, no output schema), description covers listing templates and how to use the result. Lacks mention of returned fields, but sufficient for agent to infer basic list behavior.

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?

No parameters defined; schema coverage is 100%. Baseline for 0 parameters is 4, and description adds no further parameter semantics needed.

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

Purpose5/5

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

Description clearly states verb 'List' and resource 'templates (marketplace, snapshots)', distinguishing from sibling tools like ruvds_list_os. It provides specific resource type and context for usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly states when to use: to obtain template_id for ruvds_create_server instead of os_id. This provides clear guidance and differentiates from listing OS options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_mark_all_notificationsD

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_mark_notification_readD

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes
`notification_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_notifications_countD

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_server_actionD

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_server_costD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_server_networksD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_server_paid_tillD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruvds_server_power_stateD

ParametersJSON Schema

Name	Required	Description	Default
`virtual_server_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

26 tool updatesv0.1.0Jul 30, 2026
- First observedruvds_change_server
- First observedruvds_create_server
- First observedruvds_create_ssh_key
- First observedruvds_delete_server
- First observedruvds_delete_ssh_key
- First observedruvds_get_action
- First observedruvds_get_balance
- First observedruvds_get_server
- First observedruvds_get_ssh_key
- First observedruvds_list_actions
- First observedruvds_list_datacenters
- First observedruvds_list_notifications
- First observedruvds_list_os
- First observedruvds_list_payments
- First observedruvds_list_servers
- First observedruvds_list_ssh_keys
- First observedruvds_list_tariffs
- First observedruvds_list_templates
- First observedruvds_mark_all_notifications
- First observedruvds_mark_notification_read
- First observedruvds_notifications_count
- First observedruvds_server_action
- First observedruvds_server_cost
- First observedruvds_server_networks
- First observedruvds_server_paid_till
- First observedruvds_server_power_state

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.7/5.0

Disambiguation2/5

Many tools lack descriptions (e.g., ruvds_get_action, ruvds_server_action, ruvds_change_server), making it hard to distinguish their purposes. Names like ruvds_server_action, ruvds_server_cost, and ruvds_get_server overlap in scope without clear differentiation.

Naming Consistency3/5

All tools share the 'ruvds_' prefix, but the naming pattern varies: some use verb_noun (list_servers, create_server), others noun_verb (server_action, server_cost), and singular/plural is inconsistent (list_servers vs get_server).

Tool Count2/5

26 tools is a large surface for a VPS management server, especially since many have no descriptions and cover niche actions (e.g., notifications, payments). The count feels bloated and could be consolidated.

Completeness3/5

The tool set covers server lifecycle (create, delete, get, list), datacenters/tariffs/OS, SSH keys, and notifications/payments. However, the absence of descriptions for many tools leaves uncertainty about gaps, and an update or rename tool is missing or unclear.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hostinger-api-mcpOAuth
io.github.hostinger
MCP server for Hostinger API
Cloud Platforms Developer Tools
1150
dnsimple A
io.usefulapi
MCP server for DNSimple — domains, DNS zone records, availability, pricing and contacts.
Networking & Infrastructure Cloud Platforms
122
Contabo (VPS) MCP Server C
ai.com.mcp
Contabo API (v1.0.0) as MCP tools for cloud provisioning, and management. Powered by HAPI MCP server
Cloud Platforms Virtualization
12427
lemonsqueezy A
io.usefulapi
MCP server for Lemon Squeezy — stores, products, orders, subscriptions, license keys.
E-commerce & Retail Payments & Billing
182

Related MCP Servers

Hetzner Cloud MCP Server —
Cloud Platforms Virtualization Shell Access
wbf-solutions
A
license
Not graded
quality
C
maintenance
Open-source MCP server for managing Hetzner Cloud infrastructure with two management layers: * Layer 1 — Hetzner Cloud API (35 tools): Server power control, metrics, snapshots, backups, firewalls, DNS zones and records, rescue mode, server rebuild and rescale. Works even when the server OS is unresponsive. * Layer 2 — SSH (25 tools): Service management (systemd), Nginx config and reload,
Updated 5 months ago (2026-04-12 18:44 UTC)
MIT
OVHcloud MCP Server
Cloud Platforms Networking & Infrastructure Shell Access
hlebtkachenko
A
license
B
quality
D
maintenance
Manage VPS, domains, DNS, billing, and execute SSH commands from any MCP-compatible client. 27 tools + full API discovery across 500+ OVH endpoints.
Updated 6 months ago (2026-03-14 23:37 UTC)
27
3
MIT
hetzner-mcp-server
Cloud Platforms Networking & Infrastructure
lazyants
A
license
A
quality
A
maintenance
MCP server for the Hetzner Cloud API. Manage servers, networks, volumes, firewalls, load balancers, and more through the Model Context Protocol.
Updated 6 days ago (2026-08-31 07:11 UTC)
185
301
4
Functional Source , Version 1.1, MIT Future
MoySklad MCP Server
CRM E-commerce & Retail
theYahia
A
license
C
quality
B
maintenance
MCP server for MoySklad (МойСклад) warehouse and CRM management API. 21 tools covering the full order lifecycle: products, stock, counterparties, customer orders, shipments, supplies, warehouses, organizations, reports, and webhooks.
Updated 2 months ago (2026-06-23 11:36 UTC)
60
100
5
MIT

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/firstend/mcp_ruvds.com'

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