MCP или еще один повод уважать Anthropic
Сегодня всё больше разработчиков задумываются о том, как подключить большие языковые модели (LLM) к своим инструментам и данным. Но сталкиваются с кучей проблем: модели изолированы, не понимают, что делает API, и не могут просто так «пойти» в интернет. И вот здесь появляется MCP (Model Context Protocol).
Это открытый стандарт, созданный Anthropic. Он решает ключевую проблему: как дать LLM доступ к внешним данным и инструментам, не ломая их внутреннюю безопасность.
Да, у нас есть RESTful API. Но:
— Большинство LLM работают в «песочнице» без доступа в интернет;
— Даже если бы доступ был, модель не знает, как вызвать ваш API, какие параметры использовать и как интерпретировать ответ.
MCP решает эту задачу: он описывает, что делает ваш сервис, как с ним работать и что возвращается в ответ.
Три типа возможностей
1. Resources — данные, которые можно "прочитать", аналог GET-запросов
2. Tools — функции, которые можно вызвать (например, поиск видео)
3. Prompts — шаблоны запросов, помогающие пользователю формировать нужный вызов.
Пример: YouTube
Структура:
1. Модуль YouTube-поиска — обёртка над пакетом
2. MCP-сервер — оборачивает этот модуль и превращает его в доступный инструмент для LLM.
И MCP-сервер, использующий этот модуль:
LLM теперь может вызывать
Автогенерация MCP из FastAPI
Если ваш API уже на FastAPI, вы можете автоматически создать MCP-интерфейс через
Но это подойдёт, если вы точно знаете, что API и MCP будут едины и не потребуется различать их архитектурно.
Где это уже используется?
Пример из видео — интеграция с Claude Desktop, где в конфигурации можно указать локальный MCP-сервер:
#LLM
Сегодня всё больше разработчиков задумываются о том, как подключить большие языковые модели (LLM) к своим инструментам и данным. Но сталкиваются с кучей проблем: модели изолированы, не понимают, что делает API, и не могут просто так «пойти» в интернет. И вот здесь появляется MCP (Model Context Protocol).
Это открытый стандарт, созданный Anthropic. Он решает ключевую проблему: как дать LLM доступ к внешним данным и инструментам, не ломая их внутреннюю безопасность.
Да, у нас есть RESTful API. Но:
— Большинство LLM работают в «песочнице» без доступа в интернет;
— Даже если бы доступ был, модель не знает, как вызвать ваш API, какие параметры использовать и как интерпретировать ответ.
MCP решает эту задачу: он описывает, что делает ваш сервис, как с ним работать и что возвращается в ответ.
Три типа возможностей
1. Resources — данные, которые можно "прочитать", аналог GET-запросов
2. Tools — функции, которые можно вызвать (например, поиск видео)
3. Prompts — шаблоны запросов, помогающие пользователю формировать нужный вызов.
Пример: YouTube
Структура:
1. Модуль YouTube-поиска — обёртка над пакетом
youtube-search
2. MCP-сервер — оборачивает этот модуль и превращает его в доступный инструмент для LLM.
def search_youtube(query, max_results):
# Используем youtube_search
...
return result_dict
И MCP-сервер, использующий этот модуль:
from fast_mcp import FastMCP
server = FastMCP(name="videos")
server.add_tool("get_videos", search_youtube)
LLM теперь может вызывать
get_videos()
, передав строку запроса — и получить отформатированный список роликов.Автогенерация MCP из FastAPI
Если ваш API уже на FastAPI, вы можете автоматически создать MCP-интерфейс через
fast_mcp
.
from fast_mcp.contrib.fastapi import convert_app_to_mcp
app = FastAPI()
# ... API endpoints
mcp_server = convert_app_to_mcp(app)
Но это подойдёт, если вы точно знаете, что API и MCP будут едины и не потребуется различать их архитектурно.
Где это уже используется?
Пример из видео — интеграция с Claude Desktop, где в конфигурации можно указать локальный MCP-сервер:
{
"name": "YouTube Videos",
"command": "uv",
"args": {
"dir": "~/youtube_service",
"file": "run_mcp.py"
}
}
#LLM
❤7🗿1
ИИ против разума: битва за навыки программиста
Сегодня многие программисты всё чаще доверяют работу LLM, теряя навык писать даже базовые конструкции вроде простого цикла. Но большие языковые модели не понимают реальную архитектуру проекта, а лишь подбирают правдоподобный текст. В итоге ключевая ответственность — понимание задачи, принятие архитектурных решений и контроль качества — всё ещё остаётся за живым человеком. В статье на Tproger разобрались, как сохранить за собой гордое звание «разработчик», а не «одобрятор автокомплита».
#LLM
@zen_of_python
Сегодня многие программисты всё чаще доверяют работу LLM, теряя навык писать даже базовые конструкции вроде простого цикла. Но большие языковые модели не понимают реальную архитектуру проекта, а лишь подбирают правдоподобный текст. В итоге ключевая ответственность — понимание задачи, принятие архитектурных решений и контроль качества — всё ещё остаётся за живым человеком. В статье на Tproger разобрались, как сохранить за собой гордое звание «разработчик», а не «одобрятор автокомплита».
#LLM
@zen_of_python
👍4👎3