Back to Blog

AI and MCP / D10

30 подсказок и 21 ресурс: почему MERX — единственный полнофункциональный MCP сервер

MCP имеет три примитива, а не один

Model Context Protocol определяет три типа возможностей, которые сервер может предоставить AI клиенту:

  1. Tools — исполняемые действия (отправить транзакцию, купить энергию, выполнить свап)
  2. Prompts — предварительно подготовленные шаблоны, которые направляют модель через сложные рабочие процессы
  3. Resources — структурированные данные, которые модель может читать (ценовые фиды, параметры сети, документация)

Большинство MCP серверов реализуют только tools. Они предоставляют несколько вызываемых функций, и на этом успокаиваются, позиционируя себя как «MCP-совместимые». Это технически верно в том же смысле, как автомобиль с двигателем, но без руля, технически является транспортным средством.

Tools одни дают модели действия, но не дают руководства о том, когда или как их использовать. Без prompts модель должна разбираться со сложными многошаговыми рабочими процессами с нуля каждый раз. Без resources модель не имеет структурированных данных для справки — она должна делать вызовы инструментов, просто чтобы прочитать информацию, которая должна быть пассивно доступна.

MERX реализует все три примитива: 60 tools, 30 prompts и 21 ресурс. Эта статья объясняет, что делает каждый примитив, почему все три важны и как MERX использует их для создания MCP сервера, качественно отличающегося от реализаций, основанных только на tools.

Примитив 1: Tools (Действия)

Tools — наиболее интуитивный примитив. Tool это функция, которую модель может вызвать для выполнения действия. У неё есть имя, описание, типизированные параметры и структурированный ответ.

MERX предоставляет 60 tools, охватывающих полный спектр операций блокчейна TRON:

Операции с кошельком

Энергетический рынок

DEX торговля

Автоматизация

Продвинутые функции

У каждого tool есть определение JSON Schema для его параметров, описание на естественном языке и структурированные типы возвращаемых значений. Модель точно знает, что делает каждый tool, какие параметры ему нужны и что он вернёт.

Но tools одних недостаточно.

Примитив 2: Prompts (Шаблоны)

Prompt это предварительно подготовленный шаблон, который модель может использовать для обработки конкретного типа запроса. Думайте о нём как о рецепте: «Когда пользователь просит X, вот пошаговый подход, включая какие tools вызывать, в каком порядке и как интерпретировать результаты».

MERX предоставляет 30 prompts, организованных в 10 категорий.

Начало работы (3 prompts)

setup_wallet

Шаблон: пройти пользователя через конфигурацию кошелька
Шаги:
  1. Объяснить безопасность приватного ключа
  2. Вызвать set_private_key
  3. Вызвать get_trx_balance для проверки
  4. Вызвать check_address_resources для базовой информации
  5. Рекомендовать следующие шаги на основе баланса

first_energy_purchase

Шаблон: направлять первых покупателей энергии
Шаги:
  1. Объяснить, что такое energy и почему это важно
  2. Вызвать get_prices для показа обзора рынка
  3. Помочь выбрать сумму и длительность
  4. Вызвать create_order или create_paid_order
  5. Проверить делегирование через check_address_resources

platform_overview

Шаблон: объяснить возможности MERX
Содержание: структурированный обзор всех tools, prompts и resources
  с примерами когда использовать каждый

Управление энергией (4 prompts)

buy_cheapest_energy

Шаблон: найти и купить энергию по лучшей цене
Шаги:
  1. Вызвать get_best_price с параметрами пользователя
  2. Показать сравнение цен между провайдерами
  3. Подтвердить покупку у пользователя
  4. Вызвать create_order
  5. Опрашивать подтверждение делегирования

compare_providers

Шаблон: детальное сравнение провайдеров
Шаги:
  1. Вызвать get_prices для всех провайдеров
  2. Рассчитать стоимость для конкретных потребностей пользователя
  3. Представить таблицу сравнения
  4. Включить метрики надёжности и скорости
  5. Рекомендовать лучший вариант с обоснованием

optimize_costs

Шаблон: анализ расходов и предложение оптимизаций
Шаги:
  1. Просмотреть историю заказов
  2. Анализировать паттерны цен
  3. Идентифицировать возможности для постоянных заказов
  4. Рассчитать потенциальную экономию
  5. Представить план оптимизации

ensure_resources_for_tx

Шаблон: подготовить ресурсы для конкретной транзакции
Шаги:
  1. Оценить energy для планируемой транзакции
  2. Проверить текущие ресурсы
  3. Рассчитать дефицит
  4. Купить если требуется
  5. Подтвердить готовность

Выполнение транзакций (4 prompts)

send_usdt

Шаблон: завершить переводу USDT с оптимизацией ресурсов
Шаги:
  1. Проверить адрес получателя
  2. Оценить energy
  3. Обеспечить ресурсы
  4. Выполнить передачу
  5. Проверить на цепи

send_trx

Шаблон: передача TRX (проще — energy не требуется)
Шаги:
  1. Проверить адрес получателя
  2. Проверить bandwidth
  3. Выполнить передачу
  4. Проверить на цепи

swap_tokens

Шаблон: DEX свап с полным конвейером
Шаги:
  1. Получить котировку
  2. Просмотреть влияние цены и slippage
  3. Проверить нужно ли одобрение
  4. Обеспечить ресурсы для одобрения + свопа
  5. Выполнить свап
  6. Проверить результат

execute_complex_intent

Шаблон: многошаговый план транзакций
Шаги:
  1. Помочь пользователю определить шаги
  2. Смоделировать все шаги
  3. Просмотреть общие расходы
  4. Выбрать стратегию ресурсов
  5. Выполнить intent
  6. Отчёт о результатах

Автоматизация (4 prompts)

setup_standing_order

Шаблон: конфигурировать автоматические покупки энергии
Шаги:
  1. Понять потребности пользователя (объём, время, бюджет)
  2. Рекомендовать тип триггера
  3. Установить соответствующие ограничения
  4. Создать постоянный заказ
  5. Объяснить мониторинг и управление

setup_delegation_monitor

Шаблон: конфигурировать автоматическое обновление делегирований энергии
Шаги:
  1. Просмотреть текущие делегирования
  2. Установить окно обновления
  3. Конфигурировать защиту цены
  4. Установить каналы уведомлений
  5. Создать монитор

setup_balance_monitor

Шаблон: конфигурировать оповещения и действия на основе баланса
Шаги:
  1. Анализировать текущие паттерны использования ресурсов
  2. Рекомендовать уровни порогов
  3. Конфигурировать действие (купить, обеспечить или уведомить)
  4. Установить ограничения по бюджету
  5. Создать монитор

review_automation

Шаблон: аудит и оптимизация существующей автоматизации
Шаги:
  1. Вывести все постоянные заказы и мониторы
  2. Просмотреть историю выполнения
  3. Идентифицировать недостаточно эффективные правила
  4. Предложить улучшения
  5. Применить изменения если одобрено

Анализ (4 prompts)

analyze_prices

Шаблон: анализ цен на рынке
Шаги:
  1. Получить текущие цены от всех провайдеров
  2. Получить историю цен
  3. Идентифицировать тренды и паттерны
  4. Рассчитать оптимальное время покупки
  5. Представить анализ с графиками

calculate_savings

Шаблон: рассчитать экономию от использования делегированной энергии
Шаги:
  1. Оценить energy для типов транзакций пользователя
  2. Рассчитать стоимость с TRX сжиганием
  3. Рассчитать стоимость с покупкой энергии
  4. Показать процент экономии
  5. Спроецировать годовую экономию при заданном объёме

estimate_transaction_cost

Шаблон: оценка стоимости для любого типа транзакции
Шаги:
  1. Идентифицировать тип транзакции
  2. Смоделировать с точными параметрами
  3. Показать требования по energy и bandwidth
  4. Показать стоимость с и без делегирования
  5. Рекомендовать оптимальный подход

portfolio_overview

Шаблон: полный обзор аккаунта
Шаги:
  1. Проверить все балансы (TRX, USDT, другие токены)
  2. Проверить распределение ресурсов
  3. Просмотреть активные делегирования
  4. Подвести итоги активных правил автоматизации
  5. Представить финансовый обзор

Управление аккаунтом (3 prompts)

account_setup, deposit_guide, withdrawal_guide — пошаговые шаблоны для операций жизненного цикла аккаунта.

x402 (2 prompts)

x402_purchase — направлять через поток покупки без регистрации.

x402_explain — объяснить как работает x402 и когда его использовать.

Информация о сети (2 prompts)

explain_energy, explain_bandwidth — образовательные шаблоны, объясняющие ресурсную модель TRON используя данные из resources.

Устранение неполадок (2 prompts)

transaction_failed, delegation_not_arrived — диагностические шаблоны, которые помогают идентифицировать и решать частые проблемы.

Интеграция (2 prompts)

sdk_quickstart, api_integration — шаблоны для разработчиков, интегрирующих MERX в свои приложения.

Почему Prompts важны

Без prompts, модель получившая запрос «помоги мне купить энергию» должна была бы:

  1. Разобраться какие tools релевантны
  2. Определить правильный порядок операций
  3. Решить какую информацию собрать первой
  4. Обработать граничные случаи, о которых она может не знать

С prompt buy_cheapest_energy, модель имеет проверенный, оптимизированный рабочий процесс, который обрабатывает граничные случаи, представляет информацию в правильном формате и следует правильной последовательности операций. Разница как между выдачей человеку набора инструментов и выдачей инструментов плюс руководство.

Примитив 3: Resources (Данные)

Resources это структурированные данные, которые модель может читать без совершения вызова действия. В отличие от tools, которые что-то делают, resources что-то предоставляют — они делают информацию пассивно доступной.

MERX предоставляет 21 ресурс: 14 статических и 7 динамических шаблонов.

Статические ресурсы (14)

Статические ресурсы предоставляют фиксированные справочные данные, которые не изменяются между сеансами:

merx://docs/getting-started
merx://docs/energy-explained
merx://docs/bandwidth-explained
merx://docs/resource-model
merx://docs/providers-overview
merx://docs/x402-protocol
merx://docs/standing-orders-guide
merx://docs/monitors-guide
merx://docs/intent-execution-guide
merx://docs/api-reference
merx://docs/sdk-js
merx://docs/sdk-python
merx://docs/faq
merx://docs/troubleshooting

Когда модель читает merx://docs/energy-explained, она получает структурированный документ, объясняющий ресурсную модель energy TRON — что такое energy, как она потребляется, как работает делегирование и как это соотносится с затратами TRX. Эта информация доступна немедленно, без каких-либо вызовов API или вызовов инструментов.

Динамические шаблонные ресурсы (7)

Шаблонные ресурсы принимают параметры и возвращают данные, специфичные для запроса:

merx://prices/current
merx://prices/history/{period}
merx://providers/{provider_name}
merx://account/{address}/resources
merx://account/{address}/balances
merx://network/parameters
merx://network/chain-info

Например, merx://prices/current возвращает текущие цены на энергию от всех провайдеров в структурированном формате:

{
  "timestamp": "2026-03-30T12:00:00Z",
  "prices": [
    {
      "provider": "sohu",
      "energy_1h": 0.0000526,
      "energy_24h": 0.0000498,
      "available": true,
      "min_amount": 65000
    },
    {
      "provider": "catfee",
      "energy_1h": 0.0000540,
      "energy_24h": 0.0000510,
      "available": true,
      "min_amount": 65000
    }
  ]
}

И merx://account/{address}/resources возвращает текущее распределение ресурсов для любого адреса:

{
  "address": "TYourAddress...",
  "energy": {
    "available": 487231,
    "total": 500000,
    "used": 12769,
    "delegated_from": [
      {
        "amount": 500000,
        "provider": "sohu",
        "expires_at": "2026-03-31T02:00:00Z"
      }
    ]
  },
  "bandwidth": {
    "available": 1342,
    "total": 1500,
    "free_remaining": 1342
  }
}

Почему Resources важны

Resources дают модели контекст без затрат на вызовы инструментов. Когда пользователь спрашивает «какой у меня баланс энергии?», модель может проверить ресурс merx://account/{address}/resources напрямую. Когда модели нужно обратиться к документации о постоянных заказах перед созданием одного, она читает merx://docs/standing-orders-guide.

Без resources каждая информация требует вызова инструмента. Модель должна была бы вызвать get_prices чтобы увидеть текущие цены, даже хотя эта информация могла быть пассивно доступна. Различие между моделью, которая должна активно запрашивать каждый кусок данных (только tools) и моделью, которая имеет богатую информационную среду для справки (tools + resources).

Преимущество полного протокола

Когда все три примитива работают вместе, модель работает на принципиально другом уровне:

Сценарий: пользователь спрашивает «помоги мне установить автоматизацию энергии»

MCP сервер только с tools:

  1. Модель угадывает какие tools существуют для автоматизации
  2. Вызывает tools в последовательности методом проб и ошибок
  3. Может пропустить важные опции конфигурации
  4. Нет руководства по лучшим практикам
  5. Нет справочного материала

Полнофункциональный MCP сервер MERX:

  1. Модель читает merx://docs/standing-orders-guide для справочного материала
  2. Модель активирует prompt setup_standing_order для пошагового рабочего процесса
  3. Модель читает merx://prices/history/7d чтобы рекомендовать пороги цен
  4. Модель вызывает tool create_standing_order с оптимизированными параметрами
  5. Модель читает merx://docs/monitors-guide и предлагает дополнительные мониторы
  6. Модель вызывает tool create_monitor для защиты истечения делегирования
  7. Результат: полностью, хорошо сконфигурированная автоматизация с решениями, подтверждёнными документацией

Подход полного протокола не просто немного лучше — он производит качественно отличающиеся результаты, потому что модель имеет доступ к руководству (prompts), знаниям (resources) и способности (tools) одновременно.

Что упускают другие MCP серверы

Обзор связанных с блокчейном MCP серверов по состоянию на начало 2026 показывает последовательную закономерность:

Data table
СерверToolsPromptsResourcesПолный протокол
Generic ETH MCP5-800Нет
Solana MCP10-1200Нет
Bitcoin MCP3-400Нет
Multi-chain MCP15-2000Нет
MERX523021Да

Ни один другой MCP сервер блокчейна не реализует prompts или resources. Все они только с tools, что означает:

MERX — единственный MCP сервер, где модель имеет полную операционную среду — способность действовать (tools), знание как действовать (prompts) и данные для информирования решений (resources).

Числа

MERX по числам:

Для AI агента подключённого к MERX, это означает:

Заключение

MCP это протокол с тремя примитивами, а не один. Реализация только tools это как создание API с эндпоинтами, но без документации и без потоков данных. Это работает, технически, но это заставляет потребителя разбираться во всём самому.

MERX реализует полный протокол, потому что полный протокол это как MCP был спроектирован для использования. Tools для действия. Prompts для руководства. Resources для знания. Все три работают вместе, чтобы создать среду, где AI агент может работать на блокчейне TRON с той же глубиной возможности как человеческий разработчик с многолетним опытом.

Тридцать prompts. Двадцать один ресурс. Пятьдесят два инструмента. Ни один другой MCP сервер блокчейна даже близко не подходит.

Ссылки:

Попробуйте прямо сейчас с AI

Добавьте MERX в Claude Desktop или любого MCP-совместимого клиента — без установки, без API ключа для read-only инструментов:

{
  "mcpServers": {
    "merx": {
      "url": "https://merx.exchange/mcp/sse"
    }
  }
}

Спросите у вашего AI агента: «Какая самая дешёвая TRON энергия прямо сейчас?» и получите текущие цены от всех подключённых провайдеров.

Полная документация MCP: merx.exchange/docs/tools/mcp-server

All Articles