Magic MCP теперь ведёт к 21st MCP через совместимый переходный пакет: старые ключи сброшены, а доступные инструменты определяет новая учётная запись. Команде нужно заменить ключ, проверить tools/list и принять код UI-компонента на тестовой ветке. Этот маршрут полезен для поддержки старой конфигурации и аккуратного перехода на рекомендуемое подключение.
Новый маршрут
Magic MCP сохранился как совместимый переходный пакет к 21st MCP. Старые ключи сброшены; команде нужен новый ключ, проверка tools/list и ревью кода компонента перед включением в проект.
В официальном README Magic MCP разработчик описывает переход от отдельного пакета к единому серверу 21st MCP. Существующая запись клиента с пакетом Magic может продолжать работу после замены ключа, поскольку запросы идут к новому серверу. Для новой настройки документация рекомендует 21st CLI либо прямое HTTP-подключение. Выбор пути команда фиксирует в рабочем описании конфигурации, чтобы поддержка знала, какой компонент отвечает за соединение.
Поисковый запрос про Magic MCP часто ведёт к старым инструкциям с прежними именами инструментов. Старые подсказки агента могут расходиться с набором инструментов, доступным учётной записи. Перед задачей разработчик запрашивает перечень инструментов через tools/list, затем сверяет фактические имена, входные параметры и права. Старые названия сервер способен переводить в новые, но проектные инструкции лучше строить по актуальному ответу сервера.
| Объект | Что проверить | Решение команды |
|---|---|---|
| Старая запись Magic | Путь подключения и источник ключа | Оставить временно или заменить |
| Новый 21st MCP | Ответ tools/list для аккаунта | Зафиксировать доступные вызовы |
| Компонент UI | Полученный код и зависимости | Принять после ревью |
Тема отличается от общего формата интерактивных карточек MCP UI. Здесь результатом служит код компонента для приложения и его проверка в репозитории, а вопрос состоит в миграции конкретной интеграции 21st.dev. Общее устройство инструментов протокола разобрано в материале про MCP tools; эта статья ведёт по прикладному маршруту смены ключа и приёмки кода.
Ключ и доступ
Ключ из старой консоли Magic уже сброшен, поэтому его сохранение в конфигурации даст ошибку доступа. Ответственный получает новый ключ на официальной странице 21st MCP и передаёт его через утверждённое хранилище секретов. В репозиторий, заявку на изменение и переписку попадает только имя переменной или ссылка на внутренний порядок выдачи. Значение ключа исключают из примеров команд, журналов клиента и снимков экрана.
Для существующего проекта инженер сначала описывает текущее подключение: клиент, рабочее окружение, запись сервера и ответственного за ключ. Затем выбирает либо сохранение совместимого пакета Magic на переходном этапе, либо переход на рекомендованное подключение 21st. Этот выбор влияет на способ сопровождения, но оба пути ведут к серверу 21st MCP. В каждом случае доступ определяют новый ключ и возможности учётной записи; название старого пакета указывает лишь на способ подключения.
Серверная сторона выдаёт доступ к инструментам, а локальный клиент решает, какие вызовы показать агенту. Команда отдельно проверяет границы обоих уровней. Промпт с просьбой «используй только поиск» помогает сформулировать задачу, но серверные права и разрешения клиента должны ограничивать фактические действия. Для учебной проверки создают тестовую ветку и отдельный контур ключа согласно внутреннему регламенту, чтобы результат чтения и возможного изменения файлов остался под контролем.
После замены ключа сверяют авторизацию, а затем перечень доступных инструментов. Ошибка подключения, пустой список и отсутствие конкретного вызова означают разные состояния; каждое получают собственную запись в журнале проверки. Сам факт успешного соединения ещё оставляет открытым вопрос о праве получать код компонента или запускать генерацию. Владелец интеграции отмечает итог по каждому требуемому действию.
Список инструментов
Проверка начинается с tools/list в том клиенте, где команда планирует работу. Ответ сохраняют как техническое свидетельство без ключа и личных данных. Для задачи поиска и адаптации UI достаточно увидеть доступность поиска каталога и получения компонента. README приводит новые названия search и get_component. Вызовы generate и iterate_generation сервер показывает лишь при включённом доступе к размещённой генерации. Сценарий поиска готового кода остаётся возможным при наличии search и get_component в списке.
- Запишите клиент и способ подключения, выполните штатную проверку соединения и получите актуальный tools/list.
- Выберите доступный поиск компонента по задаче интерфейса. Сохраните ссылку на источник и краткое описание назначения найденного варианта.
- Получите код выбранного компонента только при наличии соответствующего инструмента и права аккаунта. Зафиксируйте состав файлов и внешних зависимостей.
- Создайте изменение в тестовой ветке, адаптируйте стили и свойства под проект, затем передайте diff разработчику на ревью.
Прежние имена Magic из старых подсказок можно встретить в журнале команды. README описывает их преобразование сервером, но эту совместимость удобно считать переходным механизмом. Новые инструкции пишут по фактическому списку и проверенным параметрам. При изменении доступа к генерации список инструментов обновляют через клиент; решение о повторном вызове принимает разработчик после просмотра причины отказа. Одинаковый текст запроса при другом наборе прав способен привести к иному маршруту.
Смысл проверки — получить воспроизводимую цепочку от найденного исходника до конкретного изменения в приложении. На этом шаге команда видит границу автоматизации и объём ручной адаптации. Дальше понадобится проверка кода, поскольку доступный инструмент сообщает о возможности вызова, а качество результата устанавливает ревью.
Хотите проверить переход Magic MCP в своём проекте?
Ревью компонента
Код из каталога или результата генерации рассматривают как внешний материал. Разработчик сверяет зависимости, лицензирование, сетевые обращения, обработку пользовательского ввода и соответствие принятому стилю приложения. Языковая модель может объяснить структуру и предложить гипотезы о проблемных местах, однако решение об использовании исходника принимает человек. Автоматический анализ помогает найти сигнал, а подтверждение прав и допустимости заимствования остаётся у владельца прав и ответственного специалиста.
В тестовой ветке инженер переносит только нужные файлы, сохраняет ссылку на происхождение и описывает изменения. Он проверяет сборку приложения, визуальное поведение и доступность элементов интерфейса в контексте реальной страницы. Компонент, который выглядит убедительно в превью, может конфликтовать с темами, маршрутами или данными продукта. Поэтому приёмка относится к адаптированному коду в проекте; картинка в каталоге служит предварительным ориентиром.
Отдельно проверяют действия компонента. Если кнопка отправляет форму либо открывает доступ к данным, сервер приложения должен повторно проверять полномочия и условия записи. Полномочия на запись задаёт сервер приложения; сгенерированный агентом текст остаётся проектным материалом. Для дизайн-исходников соседним процессом служит работа с Figma MCP; здесь исходник приходит из 21st MCP, а финальная проверка остаётся за командой приложения.
Сверьте назначение компонента с задачей, состав зависимостей с политикой проекта, права на код с источником и поведение с тестовой страницей. Сохраните diff, ссылку на исходник и решение ревьюера в задаче разработки.
После замечаний разработчик правит код и повторяет нужные проверки. Генерацию можно использовать как источник нового черновика лишь при доступном инструменте и принятом маршруте. Ветка попадает в общий код после обычного согласования команды, чтобы последующие изменения имели понятного владельца.
Пилот и стоимость
Проектный пилот удобно ограничить учебной страницей и синтетическими данными. Команда готовит задачу на компонент, выбирает путь подключения, получает новый ключ по внутреннему порядку и фиксирует ответ tools/list. Затем она ищет вариант, получает код при доступном инструменте, адаптирует его в ветке и проводит ревью. Этот порядок задаёт предстоящую проверку и остаётся проектным предложением.
Критерии приёмки формулируют заранее: клиент подключается с новым ключом, список инструментов совпадает с разрешённым маршрутом, источник кода указан, секрет отсутствует в репозитории, сборка и визуальная проверка проходят на тестовой странице. Для действий с данными добавляют проверку серверного допуска. Спорный результат останавливает переход к общей ветке и получает владельца исправления. Журнал фиксирует, какая версия исходника проверялась и кто принял решение.
Если команда выбирает другой источник UI, полезно сравнить рабочие границы инструментов по задачам проекта. Материал о прототипах интерфейса v0 описывает соседний путь подготовки компонента. Magic MCP в этой статье рассматривается как конкретный переход к 21st MCP с проверкой ключа, перечня вызовов и полученного кода. Такое разграничение помогает обсуждать требуемый результат без путаницы между сервисами.
Стоимость зависит от условий доступа к 21st, сложности адаптации компонента, объёма ревью и требований проекта к проверке кода. Действующие тарифы и доступные возможности аккаунта уточняют на официальной странице сервиса; проектную оценку составляют после выбора сценария. Если нужен маршрут внедрения для команды, начните с обсуждения внедрения ИИ в рабочие процессы и принесите описание тестовой страницы и критерии приёмки.