Model Context Protocol Python: пошаговый туториал по созданию своего первого MCP-сервера
Практический туториал по Model Context Protocol Python: создание первого сервера, ключевые концепции MCP и самый быстрый путь от кастомных скриптов к переиспользуемым AI-инструментам.
Большая часть материалов о MCP останавливается на общей идее: стандартный способ подключения AI-инструментов к внешним системам. Это полезно, но мало помогает, когда вы сидите в Python-проекте и думаете, с чего начать. Это руководство идёт практическим путём. Если вы хотите разобраться в Model Context Protocol Python настолько, чтобы выпустить что-то рабочее, лучшая отправная точка — небольшой сервер, который предоставляет один инструмент, один ресурс и один понятный сценарий использования.
У этого угла зрения сейчас сильный поисковый интерес, потому что разработчики переходят от общих экспериментов с “AI-агентами” к более узкому вопросу: как подключить модели к реальным файлам, API и бизнес-логике, не изобретая каждый раз новый связующий слой? Если вы всё ещё создаёте своего первого агента, начните с нашего руководства Создание AI-агентов на Python.
Почему эта тема сейчас в тренде
MCP вышел из узкоспециализированных разговоров о протоколе в основной рабочий процесс разработчиков.
В декабре 2025 года Anthropic объявила, что MCP передаётся в Agentic AI Foundation при поддержке Anthropic, OpenAI, Microsoft, Google, AWS, Cloudflare, Block и Bloomberg. В том же заявлении Anthropic сообщила, что у MCP более 10 000 активных публичных серверов, а протокол уже используют такие продукты, как ChatGPT, Cursor, Gemini, Microsoft Copilot и VS Code. Это важно, потому что превращает MCP из интересной идеи в канал дистрибуции.
Для Python-разработчиков момент особенно удачный. Официальная страница SDK указывает Python как Tier 1 SDK, что говорит о серьёзных обязательствах по поддержке и полноте функциональности. Другими словами, стек Python MCP больше не спекулятивное ключевое слово. Он соответствует набору инструментов, у которого уже есть официальная документация, активный SDK и понятные паттерны реализации.
Что MCP на самом деле даёт Python-разработчикам
Проще всего думать о MCP так: он стандартизирует границу между AI-приложением и контекстом или действиями, которые оно может использовать.
Официальный Python SDK описывает три основных строительных блока сервера:
- tools — для действий, которые модель может вызывать
- resources — для доступного только для чтения контекста, который приложение может загружать
- prompts — для переиспользуемых шаблонов взаимодействия
Это разграничение важно.
Tools
Tools — это активная часть вашей интеграции. Они могут выполнять код, вызывать API, записывать данные или запускать побочные эффекты. Если вашему ассистенту нужно создать тикет, запросить данные у погодного API или запустить задачу — это относится к tool.
Resources
Resources — это пассивная часть. Они ведут себя скорее как GET-эндпоинты в традиционном API. Они предоставляют полезный контекст, например документацию, конфигурацию или справочные данные, ничего при этом не изменяя.
Prompts
Prompts позволяют упаковывать переиспользуемые инструкции или паттерны взаимодействия, чтобы клиенты могли вызывать их структурированным образом.
Именно это разделение и есть настоящая ценность. До MCP многие команды впихивали всё в одну громоздкую схему tool или полагались исключительно на prompt-инжиниринг. С этим протоколом архитектуру становится проще осмысливать и легче переиспользовать между клиентами.
Из моего опыта внедрения паттернов вызова инструментов в Codiste, это разграничение между tools и resources сэкономило бы нам значительное время на рефакторинг. Когда я создавал систему Document AI на основе дообученных трансформеров, мы сначала предоставляли разбор документов и как действие, и как источник данных через один и тот же интерфейс, что порождало путаницу: должна ли модель его вызывать или контекст должен предзагружаться. Разделение на уровне протокола, подобное тому, что задаёт MCP, полностью предотвратило бы эту проблему.
Сначала соберите небольшой MCP-сервер
Пример MCP-сервера ниже — это минимум, который имеет смысл запускать: один инструмент, один ресурс и достаточно структуры, чтобы потом расширять. Официальный Model Context Protocol Python SDK (modelcontextprotocol/python-sdk на GitHub, с документацией на modelcontextprotocol.io) поставляется с быстрым стартом на FastMCP, и это правильное место для начала. Он убирает детали протокола с дороги, чтобы вы могли сосредоточиться на реальной возможности, которую хотите предоставить.
Установите его через uv или pip:
1
uv add "mcp[cli]"
или:
1
pip install "mcp[cli]"
Затем начните с минимального сервера:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Demo", json_response=True)
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers."""
return a + b
@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
"""Return a greeting resource."""
return f"Hello, {name}!"
@mcp.prompt()
def greet_user(name: str) -> str:
return f"Write a friendly greeting for {name}."
if __name__ == "__main__":
mcp.run(transport="streamable-http")
Этот крошечный пример учит модели поведения, которую стоит применять почти в любом реальном сервере:
- определите возможность
- классифицируйте её как tool, resource или prompt
- запустите сервер со стандартным транспортом
- подключите его из хост-приложения или инспектора
Именно такой практический ракурс ключевого слова делает Model Context Protocol Python ценным для продвижения. Люди, которые ищут эту тему, обычно не хотят читать эссе о протоколе. Они хотят получить первый рабочий сервер, который можно адаптировать уже сегодня.
Когда MCP лучше, чем самописная связка инструментов
Если вам нужен только один приватный помощник для одного приложения, прямого вызова SDK может быть достаточно. Но MCP начинает выигрывать, как только на первый план выходят переиспользование и совместимость.
Используйте MCP, когда:
- одна и та же возможность должна работать в разных AI-клиентах
- вам нужен чёткий контракт между приложением и инструментами
- команде важно, чтобы tools, resources и prompts оставались разделёнными
- вы ожидаете, что поверхность интеграции будет расти со временем
Избегайте избыточного усложнения, если:
- вы тестируете одноразовый прототип
- логика жёстко привязана к одному приложению и не будет переиспользоваться
- вы ещё не знаете, заслуживает ли возможность формального интерфейса
Ключевая мысль в том, что MCP — это не просто доступ к модели. Это упаковка контекста и действий таким образом, чтобы их понимали другие клиенты. Это более сильная долгосрочная стратегия, чем раз за разом писать одноразовые обёртки для вызова функций. Например, вы можете предоставить RAG-систему в виде MCP resource, чтобы любой агент мог обращаться к вашей базе знаний.
Лучшие практики для продакшн-ориентированного старта
Официальный README SDK и документация по концепциям сервера указывают на несколько привычек, которые стоит выработать с самого начала.
Держите tools узкоспециализированными
Не создавайте один tool под названием do_everything. Небольшим tools проще правильно выбираться моделью, и их проще тестировать вам самим. Когда я строил рабочие процессы AI-агентов для сегментации изображений с использованием ControlNet, я усвоил это на собственном опыте: широкий tool “process_image” постоянно вызывал ошибочную маршрутизацию, а разделение на “segment_image,” “apply_controlnet” и “postprocess_output” дало модели чёткие границы принятия решений.
Помещайте данные только для чтения в resources
Если что-то должно загружаться как контекст, а не выполняться как действие, предоставляйте это как resource. Это сохраняет семантику понятной.
Используйте context только там, где это действительно помогает
Python SDK поддерживает внедрение контекста для tools, включая отчёты о прогрессе и доступ к ресурсам, управляемым жизненным циклом. Это мощная возможность, но она нужна не для каждого эндпоинта.
Начните с одного транспорта и одного клиента
SDK поддерживает такие транспорты, как stdio, SSE и Streamable HTTP. Выберите один путь, докажите работоспособность подхода, а затем расширяйтесь. OpenAI Agents SDK — один из клиентов, который хорошо работает с MCP-серверами.
Тестируйте с помощью инспектора
В быстром старте прямо указывается на MCP Inspector как способ протестировать сервер перед его подключением к полноценному хост-приложению. Это хорошая привычка, потому что она изолирует проблемы протокола от проблем продукта.
Заключительные мысли
Причина, по которой Model Context Protocol Python имеет реальную SEO-ценность прямо сейчас, проста: этот запрос сочетает трендовый импульс с немедленным намерением реализовать что-то на практике. Разработчики слышат о MCP в контексте крупных AI-продуктов, а затем сразу ищут самый быстрый путь на Python, чтобы использовать его самим.
Если это ваша цель, не начинайте с полноценной платформы для агентов. Начните с одного полезного MCP-сервера внутри Python-проекта, который вы уже хорошо понимаете. Предоставьте небольшой tool, добавьте один resource, протестируйте его с инспектором и подключите к тому клиенту, которым вы реально пользуетесь.
Такой рабочий процесс учит протоколу быстрее, чем любое абстрактное чтение. Как только всё заработает, вы сможете вырасти от единственного локального сервера до переиспользуемого интерфейса для внутренних инструментов, систем документации, рабочих процессов поддержки или автоматизации для разработчиков.
Если вам нужен конкретный следующий шаг на этой неделе, создайте небольшой MCP-сервер вокруг одной задачи, которую вы уже повторяете вручную. Обычно это самый короткий путь от любопытства к чему-то по-настоящему полезному.
Похожие статьи
- Туториал по OpenAI Agents SDK на Python - Создавайте многоагентные рабочие процессы, использующие MCP tools и resources
- Создание AI-агентов на Python - Разберитесь в цикле работы агента, использовании инструментов и паттернах памяти, которые стандартизирует MCP
- RAG on Python: Retrieval-Augmented Generation - Создайте систему извлечения знаний, которую можно предоставить как MCP resource
Источники
Machine Learning Engineer at Codiste, specializing in Generative AI, NLP, and Computer Vision. Building production AI systems with Python.