How do I use Yandex Delivery MCP?

1. Click on "Deploy 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., "@Yandex Delivery MCP Create a delivery claim for a 5 kg package from Moscow to Kazan" 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.

Yandex Delivery MCP

by aryazansev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Yandex Delivery MCP Server

Deploy on Railway

MCP (Model Context Protocol) сервер для интеграции с API Яндекс Доставки. Позволяет Claude и другим AI-ассистентам управлять доставками, отслеживать курьеров и работать с заказами.

🚀 Развернуть в интернете (1 минута)

Рекомендация: Railway - лучший бесплатный вариант

⚡ Нажмите кнопку "Deploy on Railway" выше
🔑 Добавьте API ключ Яндекс Доставки
🌐 Получите рабочий URL: https://your-app.railway.app
🎯 Используйте в AI Studio: https://your-app.railway.app/manifest

Related MCP server: Yandex AI Studio MCP Server

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

Установка через npm

npm install -g yandex-delivery-mcp

Или локальная установка

git clone https://github.com/aryazansev/-yandex-delivery-mcp.git
cd -yandex-delivery-mcp
npm install
npm run build

⚙️ Настройка

1. Получите API ключ из Яндекс Доставки

Войдите в личный кабинет Яндекс Доставки
Перейдите в раздел API / Интеграции
Создайте новый API ключ
Скопируйте ключ

2. Создайте файл конфигурации

Создайте файл ~/.yandex-delivery-mcp/.env:

mkdir -p ~/.yandex-delivery-mcp
cat > ~/.yandex-delivery-mcp/.env << 'EOF'
YANDEX_DELIVERY_API_KEY=your_api_key_here
MCP_PORT=3002
EOF

Или просто создайте .env файл в папке проекта:

YANDEX_DELIVERY_API_KEY=your_api_key_here
MCP_PORT=3002

3. Настройка (2 варианта)

Вариант A: Claude Desktop (локально)

Откройте файл конфигурации Claude Desktop:

macOS:

~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows:

%APPDATA%/Claude/claude_desktop_config.json

Добавьте:

{
  "mcpServers": {
    "yandex-delivery": {
      "command": "yandex-delivery-mcp"
    }
  }
}

Вариант B: Внешний HTTP сервер (для AI Studio и других инструментов)

Запуск HTTP сервера:

npm run server

Сервер будет доступен на:

Health: http://localhost:3002/health
Manifest: http://localhost:3002/manifest
Tools: http://localhost:3002/tools

Для AI Studio:

Запустите сервер: npm run server
В AI Studio используйте URL: http://localhost:3002/manifest
AI Studio автоматически обнаружит все доступные инструменты

4. Перезапустите Claude Desktop (если используете вариант A)

Полностью закройте и откройте заново Claude Desktop.

💬 Использование

Теперь вы можете спрашивать Claude о данных из Яндекс Доставки:

"Рассчитай стоимость доставки из Москвы в Санкт-Петербург"
"Создай заявку на доставку посылки 5 кг"
"Покажи статус заявки ABC123"
"Где сейчас курьер по заявке ABC123?"
"Получи телефон курьера для заявки ABC123"
"Найди все заявки за последние 3 дня"
"Отмени заявку ABC123"

🛠️ Доступные инструменты

Базовые операции

calculate_offers - Рассчитать варианты доставки
create_claim - Создать заявку на доставку
get_claim_info - Получить информацию о заявке
accept_claim - Подтвердить заявку
cancel_claim - Отменить заявку

Стоимость и тарифы

check_price - Проверить стоимость без создания заявки
get_tariffs - Получить доступные тарифы

Отслеживание

get_driver_phone - Получить номер телефона курьера
get_performer_position - Получить позицию курьера (координаты, скорость)
get_points_eta - Получить ETA для точек маршрута
get_tracking_links - Получить ссылки для отслеживания

Подтверждение доставки

get_confirmation_code - Получить код подтверждения
get_proof_of_delivery - Получить данные о подтверждении доставки

Редактирование

edit_claim - Редактировать заявку (до подтверждения)
apply_changes_request - Запросить изменения (после подтверждения)
apply_changes_result - Получить результат изменений
return_claim - Инициировать возврат заказа

Поиск и информация

search_claims - Поиск заявок с фильтрами
get_bulk_info - Получить информацию о нескольких заявках
get_claim_journal - Получить историю изменений заявки

Доставка в течение дня

get_delivery_methods - Получить список доступных услуг

🔧 Разработка

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

npm run build

Запуск в режиме разработки

# Для Claude Desktop (stdio)
npm run dev

# Для внешнего HTTP сервера (AI Studio)
npm run server

Тестирование через MCP Inspector

npx @modelcontextprotocol/inspector node build/index.js

Тестирование HTTP сервера

# Запустить сервер
npm run server

# Проверить эндпоинты в другой терминал
curl http://localhost:3002/health
curl http://localhost:3002/manifest
curl http://localhost:3002/tools

📝 Требования

Node.js 18+
API ключ от Яндекс Доставки
Claude Desktop (для интеграции с Claude)

📄 Лицензия

MIT License - см. файл LICENSE

🤝 Поддержка

Если у вас возникли проблемы:

Проверьте, что API ключ активен
Убедитесь, что у ключа есть нужные права доступа
Проверьте логи Claude Desktop
Создайте issue на GitHub

🔗 Ссылки

Пример использования

Создание заявки

{
  "route_points": [
    {
      "coordinates": [55.7558, 37.6173],
      "fullname": "Москва, Красная площадь, 1",
      "contact": {
        "name": "Иван",
        "phone": "+79991234567"
      }
    },
    {
      "coordinates": [59.9343, 30.3351],
      "fullname": "Санкт-Петербург, Невский проспект, 1",
      "contact": {
        "name": "Петр",
        "phone": "+79997654321"
      }
    }
  ],
  "items": [
    {
      "title": "Посылка",
      "weight": 5,
      "quantity": 1
    }
  ],
  "requirements": {
    "taxi_class": "express",
    "door_to_door": true
  }
}

Расчет стоимости

{
  "route_points": [
    {
      "coordinates": [55.7558, 37.6173]
    },
    {
      "coordinates": [59.9343, 30.3351]
    }
  ],
  "requirements": {
    "cargo_type": "van"
  }
}

Available Tools

21 tools

accept_claimD

ParametersJSON Schema

Name	Required	Description	Default
`version`	Yes	Версия заявки
`claim_id`	Yes	ID заявки

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.

apply_changes_requestD

ParametersJSON Schema

Name	Required	Description	Default
`changes`	Yes	Список изменений
`claim_id`	Yes	ID заявки

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.

apply_changes_resultD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

calculate_offersD

ParametersJSON Schema

Name	Required	Description
`due`	No	Время подачи (ISO 8601)
`requirements`	No	Требования к доставке
`route_points`	Yes	Точки маршрута (минимум 2)
`optional_return`	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.

cancel_claimD

ParametersJSON Schema

Name	Required	Description
`version`	Yes	Версия заявки
`claim_id`	Yes	ID заявки
`cancel_state`	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.

check_priceD

ParametersJSON Schema

Name	Required	Description
`requirements`	No
`route_points`	Yes	Точки маршрута
`optional_return`	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.

create_claimD

ParametersJSON Schema

Name	Required	Description
`due`	No
`items`	No	Товары
`comment`	No
`requirements`	No
`route_points`	Yes	Точки маршрута
`emergency_contact`	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.

edit_claimD

ParametersJSON Schema

Name	Required	Description
`items`	No
`comment`	No
`version`	Yes	Текущая версия заявки
`claim_id`	Yes	ID заявки
`route_points`	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.

get_bulk_infoD

ParametersJSON Schema

Name	Required	Description	Default
`claim_ids`	Yes	Список ID заявок

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.

get_claim_infoD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_claim_journalD

ParametersJSON Schema

Name	Required	Description	Default
`cursor`	No	Курсор для пагинации
`claim_id`	Yes	ID заявки

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.

get_confirmation_codeD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_delivery_methodsD

ParametersJSON Schema

Name	Required	Description	Default
`start_point`	No	Координаты начальной точки [lat, lon]

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.

get_driver_phoneD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_performer_positionD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_points_etaD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_proof_of_deliveryD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

get_tariffsD

ParametersJSON Schema

Name	Required	Description	Default
`end_point`	No	Координаты конечной точки [lat, lon]
`start_point`	No	Координаты начальной точки [lat, lon]

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.

get_tracking_linksD

ParametersJSON Schema

Name	Required	Description	Default
`claim_id`	Yes	ID заявки

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.

return_claimD

ParametersJSON Schema

Name	Required	Description
`version`	Yes	Версия заявки
`claim_id`	Yes	ID заявки
`point_id`	No	ID точки возврата

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.

search_claimsD

ParametersJSON Schema

Name	Required	Description
`limit`	No	Лимит результатов
`phone`	No	Телефон для поиска
`cursor`	No	Курсор для пагинации
`offset`	No	Смещение
`statuses`	No	Статусы заявок
`created_to`	No	Дата создания до (ISO 8601)
`created_from`	No	Дата создания от (ISO 8601)

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.

21 tool updatesv1.0.0Aug 2, 2026
- First observedaccept_claim
- First observedapply_changes_request
- First observedapply_changes_result
- First observedcalculate_offers
- First observedcancel_claim
- First observedcheck_price
- First observedcreate_claim
- First observededit_claim
- First observedget_bulk_info
- First observedget_claim_info
- First observedget_claim_journal
- First observedget_confirmation_code
- First observedget_delivery_methods
- First observedget_driver_phone
- First observedget_performer_position
- First observedget_points_eta
- First observedget_proof_of_delivery
- First observedget_tariffs
- First observedget_tracking_links
- First observedreturn_claim
- First observedsearch_claims

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.8/5.0

Scored 2026-08-02 13:20 across 21 tools

Disambiguation3/5

The tool set has several overlapping retrieval functions (e.g., get_claim_info, search_claims, get_bulk_info, get_claim_journal) and similar pricing tools (calculate_offers, check_price), which could confuse an agent without detailed descriptions. However, most tools are distinct actions on distinct resources.

Naming Consistency4/5

All tool names use snake_case and follow a verb_noun pattern (get_tracking_links, create_claim, accept_claim, etc.), which is consistent and readable. The only minor inconsistency is mixing singular and plural nouns (claim vs. claims, info vs. journal).

Tool Count4/5

With 21 tools, the server is slightly over the typical comfortable range but still reasonable for a comprehensive delivery management API covering claims, tracking, pricing, and delivery methods. Each tool appears to serve a distinct purpose, so the count is justified.

Completeness4/5

The tool surface covers the full claim lifecycle (create, edit, accept, cancel, return, search) and includes tracking, pricing, and delivery method operations, leaving few obvious gaps. Minor missing features like a dedicated 'delete' action are likely covered by cancel/return, so agents can achieve core workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Furgonetka.pl - Logistics & Shipping MCP ServerOAuth
pl.furgonetka.api
Furgonetka MCP Server is an extension for LLMs (such as Claude) that integrates AI assistants with Poland's most popular courier brokerage platform. The server enables models to interact directly with services from various couriers (including InPost, DPD, DHL, UPS, and Poczta Polska) through a single, unified interface. With this integration, your AI stops just "writing about logistics" and starts actually managing it.
E-commerce & Retail Monitoring Travel & Transportation
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
OnceAsk A
io.github.rsb6061
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
Customer Data Platforms Search Location Services
41
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

yandex-tracker-mcp
Project Management Developer Tools
brekhov-ilya
A
license
Not graded
quality
C
maintenance
MCP server for Yandex Tracker API, enabling AI assistants to search, read, create, and edit issues, as well as manage comments, attachments, and links in Yandex Tracker.
Updated a month ago (2026-08-03 06:17 UTC)
22 npm
1
MIT
Yandex AI Studio MCP Server
AI & Machine Learning Speech Processing Image & Video Processing
rusnetru
F
license
Not graded
quality
C
maintenance
MCP server for interacting with Yandex Cloud AI Studio, enabling chat, text generation, image generation, speech recognition/synthesis, embeddings, classification, search indexes, and AI agent creation with function calling.
Updated 3 months ago (2026-06-28 14:38 UTC)
-
yandex-eats-mcp
E-commerce & Retail Customer Support
yasmanmesa
A
license
A
quality
C
maintenance
MCP server for Yandex Eats Vendor Management API, enabling AI agents to manage partner operations like orders, busy mode, menu import, and feedback.
Updated 2 months ago (2026-07-29 12:55 UTC)
11
2 npm
MIT
mcp-yandex-dostavka
Travel & Transportation
A1-x-Tech
A
license
A
quality
A
maintenance
MCP server for Yandex Delivery B2B API, enabling natural language interaction to calculate delivery costs, create and manage express and platform delivery orders, track couriers, and handle pickup points.
Updated 17 days ago (2026-08-30 13:36 UTC)
16
71 npm
MIT