Как Создать Свой MCP Сервер БЫСТРО и По Шагам (n8n, TypeScript)

Друзья, всем привет. Ну что, первичный

хайп про MCP-серверы уже прошёл, и как и всегда остаётся от хайпа сугубопра практическое использование и реальная польза. Поэтому сегодня, по сути, я возвращаю должок и покажу, каким образом можно создать свой MCP-сервер и таким образом, чтобы он мог вызываться, например, из ваших клиентов, таких как CLД код Cрсор и, естественно, N8N. Раз уж мы про NV CN тут так часто говорим, мы сегодня посмотрим на массу разных опций и документацию, чтобы чуть-чуть разобраться, каким образом работают серверы, и посмотрим на архитектуру. Даже не пугайтесь, мы, естественно, это будем делать всё в таком лайтовом режиме. Естественно, посмотрим на примеры каких-то MCP-серверов и даже напишем свой таким образом, чтобы можно было работать с NCM следующим образом, чтобы мы себе могли построить простейшего агента, который использует всего лишь одну ноду, наш MCP, и отвечает на наши вопросы. Например, я спросил: "А какие у меня есть шаблоны документов? У тебя есть коммерческое предложение, юльские шаблоны, какие-то непонятные штуки, капэшки, инвойсы и прочее. И через эту же самую ноду мы могли сказать что-нибудь. А о чём соглашение о конфиденциальности? Мы видим, что наш агент задействует одну и ту же ноду, триггерит наш MCP-сервер и готовит нам ответ. Соглашение конфиденциальности. Договор заключаемый. В нём получатель обязуется не разглашать конфиденциальную информацию, использовать её только в согласованных целях и прочее, прочее. Ну что, такое интересно, поэтому сразу лайк, подписка, коммент, ну и давайте смотреть до конца. Это уже третье видео про MCP-серверы, поэтому обязательно посмотрите первые два. Там мы разбираемся, во-первых, с азами, что такое MCP, как они работают, для чего они вообще нужны, и потом мы разбираемся, как они подключаются к различным клиентам, вот таким как CURрсор, Clopп, NVM. Ну а сегодня, конечно же, мы напишем свой. Давайте чуть-чуть про теорию поговорим. Если вы

уже посмотрели предыдущее видео, вы уже должны примерно понимать, что, в принципе, архитектура MCP сервера, она довольно простая. То есть, то есть по сути MCP-сервер всегда состоит из нескольких слоёв, да? Это слой данных, это непосредственно данные, которые мы передаём, это транспортный слой, то есть это то, как мы передаём информацию, да? Есть два стандартных пути. Это стандартный input output, это стAM http. Первый способ заключается в том, что мы непосредственно коммуницируем между субпроцессами прямо на вашем компьютере, на вашем локал хосте. А этот способ очень похож, по сути, на обычные API запросы, то есть клиентосерверные запросы. куда вы отправляете какой-то вопрос, вам возвращается какой-то ответ. Мы должны понимать, что MCP-серверы состоят именно слой данных из примитивов, да? То есть это те самые тулзы, инструменты, это ресурсы, это промты, которые мы определяем как раз, когда пишем наш MCP-сервер и который могут использовать наши агенты, которые обращаются к этому MCP-серверу. Здесь я предполагаю, что вы всё-таки уже чуть-чуть знаете, что такое MCP, и знаете, каким образом открывается среда для редактирования кода, для написания кода, VS-код, курсор илидкод. Мы сегодня будем делать это на примере курсора. Сейчас не пугайтесь, мы посмотрим в код. Я открыл сервер, который, например, уже

сам использовал. Это MCP сервер от Firecroll. И здесь мы, если посмотрим, каким образом работает этот сервер, мы, если полистаем, то увидим как раз, что инициируется сам сервер. А дальше добавляются не некоторые тулзы. То есть мы видим, что тут есть инструмент Firecroll Scrape, его описание, а, правильные параметры для его вызова. Потом есть следующий: Firecroll Map, опять же, его описание, правильные параметры для его вызова и прочее, прочее. То есть, по сути, это некоторые инструкции для агента, который будет обращаться к этому MCP-серверу. для того, чтобы он мог правильно воспользоваться тем или иным инструментом. Это краеугольное знание. Но прежде чем мы начнём, давайте разберёмся, что значит вообще написать

свой MCP-сервер. Да, мы понимаем, что MCP, вообще говоря, состоит из двух частей. Это есть некоторый сервер и это есть некоторый клиент. И задача клиента, в принципе, обращаться к MCP-серверу. То есть клиент посылает какой-то запрос, а сервер ему отвечает, что у меня есть вот такие тулзы, у меня есть такие ресурсы, у меня есть такие промты, и вот как ими правильно пользоваться. То есть сервер это ответил, и клиент готов уже, например, начинать вызывать какие-то тулзы. То есть сам агент, который выступает в качестве нашего клиента, после того, как ознакомился со всеми возможными тулзами сервера и с методами их вызова, сам заполняет запрос, теперь знает, какие именно параметры нужно передать, чтобы сервер ответил правильно. Если мы перейдём обратно на сайт model, да, и почитаем документацию, то видим, что один из способов, в принципе, создать свой MCP-сервер - это использовать лэмки, да? Так как, в

принципе, все серверы очень похожи друг на друга, почему бы не использовать какой-то унифицированный пример, добавлять конкретное описание и ваши требования для вашего сервера и получать ответ. То есть мы можем открыть прямо конкретное описание, да, то есть model протокол. На этом сайте рекомендуется прямо забрать всё это описание. Здесь есть прямо примеры клиентов, матрица фич и очень много всего того, что требуется, чтобы создать правильный MCP-сервер. Соответственно, рекомендуется прямо забрать вот этот весь текст, открыть ваш редактор кода, допустим, курсор, сделать некоторое описание того, что вам нужно, то есть ваши характеристики сервера, дальше вставить прямо пример, который вы забрали с сайта Model Contex Protocol и запустить процесс. Мы попробуем с вами прямо сейчас навайп-кодить, но несколько другим путём, потому что этот процесс довольно сложный и требует, например, огромного окна контекста. Есть способы попроще. Опять же, если мы возвращаемся к архитектуре самого MCP-сервера, да, то есть самый частый, а, слой этой архитектуры - это тулзы, да, инструменты, которые могут использоваться агентами. И большой вопрос: а что это за тулзы? Да не, ну, тулзы, по сути, это некоторые операции, которые выполняет за нас сервер, и агент получает результаты исполнения этих операций. Самый частый и популярный тип тулза - это некоторый API запрос, который выполняется, отдаёт свои результаты нашему агенту, и агент уже их интерпретирует и отдаёт нам какие-то ответы. Вы знаете, что у меня есть свой продукт, который называется S for Sign. У этого S for Sign очень развита API документация для того, чтобы работать с документами. Я это говорю сейчас не для того, чтобы прорекламировать SF Sign, а для того, чтобы, например, забрать некоторые API запросы, которые мы точно знаем, как оформляются, и попробовать на основе этого построить свой MCP-сервер. Вот у меня есть некоторые запросы. А один запрос умеет возвращать список всех шаблонов документов, да? А второй запрос умеет читать эти документы по ключу шаблона. Давайте попробуем прямо на основе вот этих двух запросов поставить, построить наш MCP сервер, который умеет принимать команду "Верни все шаблоны". И следующей командой может, например, читать какой-то шаблон, ключ которого он прочитал с помощью запроса List of Teamplate. Давайте заберём прямо вот этот запрос и заберём вот этот запрос read a template. Мы возвращаемся в наш курсор. Вы же знаете, да, как устанавливать себе курсор. Если нет, то вот тут тоже будет видео, как это делается правильно. И сейчас я прямо напишу большой-большой запрос, который должен нам помочь стартануть. Я пишу: "Напиши мне готовый MCP-сервер. Я дам тебе IP запросы для подключения ключей, шаблонов и контента". Мне ещё нужно, чтобы пользователь как-то указывал IP ключи, клиентские ключи через аргументы или как-то иначе. Также дам тебе пример из документации MCB, чтобы понимал, с чем я имею дело. Дальше я прикладываю просто копипастом все курлы, да, то есть все API запросы, которые мне требуются, чтобы MCP сервер отрабатывал, и примеры респонсов, чтобы он понимал, какие именно форматы будут возвращаться. И, соответственно, такой же API запрос для контента. А в самом низу я добавлю: а вот пример сервера, который использую как reference. Дальше я возвращаюсь на GitHub иду на MCP сервер Firecroll MCP сервер и забираю именно код MCP сервера, который меня устраивает, потому что я точно знаю, что он хорошо работает и я им массу раз пользовался. И архитектура у него очень стандартная. Я прямо вставляю сюда весьвесьвесь этот код и отправляю запрос. Всё, наш курсор пошёл думать. Давайте посмотрим, какую структуру вообще проекта он нам создаст. У нас

есть пошаговые А-ду. Вот начал наш курсор создавать уже Pack Jon, да, а TS config и прочие файлы, которые обычно а нужны для того, чтобы нормально функционировали наши приложения. Кстати, пока он пишет этот сервер, вот все ссылочки, да, и ресурсы, которые мы сейчас используем, а я прикреплю в своей бесплатной Telegram-группе. Берите оттуда, чтобы взять эти примеры. Так вот, у нас наш сервер уже почти построен, да, то есть некоторая его первая итерация, и наш агент не может продраться через некоторые аспекты, но этого уже достаточно, чтобы стартануть. Мы с вами знаем, что вайп-кодинг - это, конечно, дело хорошее, но нам нужно понимать базы и аспект, да, того, что мы делаем для того, чтобы потом уже нормально это можно было довести. То есть точно, когда мы будем писать наш MCP-сервер, нам нужно будет этерировать, да? Поэтому сейчас мы пройдёмся по некоторым базовым вещам, которые точно должны быть, для того, чтобы вы знали потом на основе чего итерировать и какие вопросы задавать вашему агенту, чтобы он дописывал правильно некоторые кусочки кода. Так, изначально, естественно, у вас в сервер будут импортироваться какие-то пакеты, какие-то библиотеки, которые будут исполняться. Дальше чаще всего у вас на сервере будут требоваться некоторые переменные, которые вам будет передавать клиент для того, чтобы исполнялись запросы. Ну, например, самый базовый а подход, да, если вы вызываете какие-то API запросы через ваши ваш MCP-сервер, вам нужно сначала получить AP ключ. Апи ключ вы можете получить только от вашего клиента. Поэтому в зависимости от того, каким образом у вас организуется транспорт, да, вы можете захотеть их получить либо из хедеров, да, самого запроса, либо ещё из аргументов, либо непосредственно переменных окружения, которые у вас есть уже на вашем локальном компе. Дальше краеугольная часть - это построение самого сервера. Да, тут мы разбираться не будем, это технические вопросы. Дальше большинство серверов построены на основе того, что они делают API запросы, поэтому чаще всего у вас будет вынесена отдельная функция, да, вот здесь она называется S for sign call, где описан некоторый обобщённый метод вызова функции, да, где заполняются хедеры и где строятся боди, да, то есть тело самого запроса, которые будут прокидываться какие-то данные. А дальше обратите внимание, уже начинается вызов самих тулов, вернее, описание самих тулов. Обратите внимание, что у нас всего лишь здесь есть два тула, именно тех, которые мы изначально описали нашу нейронку построить, да. Первый называется, а, лист темплейтов, да, то есть лист шаблонов. И здесь есть описание desрипtion этого тула. То есть, смотрите, этот инструмент возвращает вам шаблоны и их ключи, потому что мы описали, что впоследствии чтение шаблонов основано нам ключах, да, которые мы получаем из вот этого API кола. Дальше, соответственно, описаны, что мы ожидаем, да, у нас должен быть API ключ, клиентский ключ. И дальше, смотрите, как раз инициируется наш непосредственный API запрос, да, SFS call, куда уже прокидывается API ключ, который был получен либо из хедера, либо из других источников. и сам body, да, то есть телозапрос, который будет готовить сама неронка. Дальше у нас есть очень похожий тул, который называется SFS Read template. И описано, что этот туolл читает наши темплейты по готовому template ключу, который мы получаем откуда-то. И дальше всё аналогично. Готовится сам запрос, да, то есть прописываются хедеры, готовится тело запроса и взывается SFS-кол. Опять всё очень похоже. И дальше штука, которую вы чаще всего можете не увидеть в других MCP запросах, а на самом деле она краеугольная. Дальше мы должны описать транспорт, да, то есть метод коммуникации с нашим MCP-сервом для того, чтобы клиенты могли с ним взаимодействовать. Как я в начале говорил, чаще всего используется либо клиент серверная коммуникация, да, либо стандартный input output. И здесь как раз описаны оба этих метода, да, в зависимости от переменных окружений, которые заданы, алгоритм будет понимать, что ему либо нужно вызывать HTPстм, да, то есть по сути обычный HTTP запрос, либо использовать стандартный input output, если мы хотим, чтобы наш сервер исполнялся прямо на нашей машине как вот локальный субпроцесс. Это очень круто, потому что даёт нам гибкость и гибкость нашим клиентам либо вызывать его со своих компьютеров, да, откуда-то с бэкэнда этот MCP-сервер, либо вообще развернуть у себя и исполнять у себя. Если честно, то самый простой MCP сервер состоит всегда из таких вещей. То есть у нас есть здесь всего лишь две тулы, список которых и методы вызова которых может получить наш агент, откуда бы то ни было, из клиента, и вызывать их. Ну что, давайте же пробовать, наконец, вызывать этот конкретный MCP-сервер. Как я говорил, его можно развернуть как субпроцесс непосредственно к нему и непосредственно с ним коммуницировать из клиента. Наверное, нам поинтереснее будет его развернуть как HTTP-транспорт. Поэтому мы сейчас сделаем такую вещь. Мы прямо сейчас попросим агента подготовить этот сервер для того, чтобы он мог

развернуться в Докере, да? То есть отдельная крутая история таких подходов в том, что вы можете свой сервер, да, развернуть в Докере, например, залить его на свой хостинг и после этого дать прямую ссылку к этому серверу для ваших клиентов. Они будут его вызывать откуда угодно. Именно поэтому так круто, что мы прописали ему транспорт http. Так, ну что, у нас всё только что подготовилось для докера. Смотрите, у нас появился Dockerфаile, у нас появился Docker ignore. И, соответственно, мы теперь можем взять и попробовать запустить контейнер с нашим MCP сервером прямо в докере. Каким образом это делается? Мы идём, вызываем терминал, нажимаем новый терминал и прописываем вот такую команду. Docker run вызываем на порте 3.000, забираем переменное окружение, чтобы просить нам жизнь из ENV файла. Ну и погнали. Нажимаем Enter. Смотрите, у нас только что развернулся контейнер, который крутится на порте 3.000 и который развернулся из образа Sforign MCP Local. Это что значит? Это значит, что мы теперь можем попробовать обратиться к этому MCP-серверу откуда угодно. Например, вот у нас также рядом крутится NVAN. Ну давайте пробовать запускать его туда. Итак, я сейчас в своём локальном NVC MAN, и я хочу к моему агенту добавить э- коммуникацию с MCP сервером. Давайте прямо так и поищем. MCP Client Tool. Давайте добавим её. Смотрите, здесь нужно прописать endpoint server transпо. Смотрите, здесь есть выбор из SSI, который depricated, то есть который уже не используется, рекомендуется не использовать. И есть тот самый HTTP streamable, о котором мы позаботились, да, и который теперь присутствуют в нашем MCP-сервере. Каким образом мы прописываем endpint? Раз у нас всё уже крутится в нашем докере, да, то мы всегда можем использовать такую конструкцию, как host docker internal, прописать конкретный порт, да, 3.000 и дальше MCP server tools to include all - это значит, что мы будем использовать все нашизы коммуницировать с сервером. Так, у нас наш сервер а готов. Давайте его, э, назовём SFS, да, то есть S for sign. И дальше пропишем такую историю в агенте. Я напишу: "Вызови SFS Tool, чтобы работать с шаблонами". Да? То есть мы оставим всё максимально просто. Но в принципе это должно дать инструкцию нашему агенту, что если тебя пользователь что-то делает с шаблонами, то всегда пробуй вызывать SF for Sign to Tool и таким образом коммуницировать. Давайте прямо откроем чат, сохранимся и спросим, какие инструменты работать с шаблонами у меня есть. Давайте по посмотрим, что у нас будет происходить. И смотрите, он нам отвечает: "У тебя есть следующие инструменты для работы с шаблонами. Просмотр списка шаблонов S for Sign их ключей для текущего клиента и чтение содержимого шаблона SF Sign по ключу шаблон теплонетки". Обратите внимание, всё это получилось потому, что мы прописывали у нас в нашем MCP-сервере прописывали дескрипшены, да, и параметры, которые ожидаются на вход этих тулов, для того чтобы они могли коре корректно исполниться. Давайте вернёмся в наш N8 CNN и скажем так, какие шаблоны есть у меня. Посмотрим, что будет делать. Так, смотрите, было обращение к MCP-серверу. И смотрите, он вернул именно ТУ, который называется Listate, и вернул Jon всех-всех-всех шаблонов. После этого он вернул это обратно в нашу нейронку для того, чтобы она могла интерпретировать эту информацию и выдала нам простой ответ. Вот все твои шаблоны, которые есть. Я могу теперь сказать: "Покажи контент соглашения конфиденциальность". И смотрите, что будет происходить. Смотрите, неронка обратится в первый раз для к нашему MCP-серверу для того, чтобы инициировать tool, а SFS listay, да? То есть сначала она получает весь список шаблонов для того, чтобы найти нужный шаблон и нужный ключ этого шаблона. И во второй раз, обратите внимание, она проставляет уже ключ шаблона для того, чтобы вернуть конкретный шаблон по этому ключу. То есть мы этим не занимаемся, а нейронка сама поняла, что нужно выбрать конкретный ключ, который соответствует шаблону, который мы только что сказали. И вот у нас соглашение конфиденциальности возвращено. Вот полный, полный текст этого соглашения, хотя мы не прокидывали вообще ничего, а только название этого шаблона. Конечно же, это самый простейший вид MCP-сервера, который можно обогащать, добавлять новые тулзы. Туда можно добавлять сложные сложносоставные тулзы. Например, в одном туле может быть сразу несколько API запросов, да, это даёт вам огромную гибкость. То есть ваш пользователь будет инициировать просто какую-то одну команду, да, а Неронка уже будет выполнять, вернее, MCP-сервер будет выполнять последовательность API запросов для того, чтобы возвращать вам корректные результаты. Друзья, на этом короткий экскурс в то, каким образом строятся шаблоны, заканчивается. Как сказал, все ресурсы, которые мы использовали, да, ссылочки я положу в свою бесплатную прогруппу. Если вам нужен конкретный код этого шаблона, я его положу в прогруппу. И вообще подключайтесь к нашей прогруппе, потому что мы там обсуждаем все нюансы и тёмные закоулки, искусственный интеллект, автоматизации, написания своих каких-то сервисов и, естественно, там куча готовых шаблонов для автоматизации вашего бизнеса. Так, в общем-то, если вы хотите развиваться в сфере искусственного интеллекта, автоматизации, то, конечно же, в прогруппу. Вообще не теряйте время, заскакивайте. Ну а на этом всё. Хорошего дня. y