(часть 02).
В прошлых постах мы сами описывали модели функцию jira_get_issue.
Но что если Jira подключена через MCP?
Тогда первый вопрос уже не «Как описать модели функцию?», а:
откуда вообще модель узнает, какие инструменты у неё есть?
Здесь появляется MCP-клиент. Он подключается к MCP-серверу и запрашивает список доступных инструментов.
Упрощённо это выглядит так:
MCP client → MCP server
tools/list
Сервер возвращает каталог доступных инструментов примерно такого вида:
{
"tools": [
{
"name": "jira_get_issue",
"description": "Получает задачу из JIRA",
"inputSchema": {
"type": "object",
"properties": {
"issue_key": {
"type": "string"
}
},
"required": ["issue_key"]
}
},
{
"name": "jira_search",
"description": "Ищет задачи в JIRA",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string"
}
}
}
}
]
}И здесь становится интересно.
Если внимательного взглянуть на этот JSON, то по сути, мы уже видели его структуру:
➖name,
➖description,
➖inputSchema
очень похожи на то описание инструмента, которое мы вручную передавали модели через API вот тут ☝.
Именно так MCP и связывает внешний инструмент с нашим агентом. ✔️
Дальше MCP-клиен передаёт полученный каталог модели.
Модель видит доступные инструменты и, если для решения задачи нужен Jira, формирует обычный tool call.
Например:
jira_get_issue
{
"issue_key": "TASK-123"
}
А MCP-клиент уже превращает этот вызов в протокольный запрос к серверу:
MCP-клиент → MCP-сервер
tools/call
jira_get_issue(TASK-123)
Сервер выполняет свою логику и возвращает результат.
Получается важное разделение:
1⃣ MCP-сервер знает, как работать с внешней системой.
2⃣ MCP-клиент знает, как разговаривать с MCP-сервером.
3⃣ модель решает, какой инструмент ей нужен.
И мы больше не пишем для каждого агента отдельную интеграцию с каждой системой.
В следующем посте предлагаю разобраться с самым интересным вопросом: где здесь вообще находится модель и кто передаёт ей список инструментов?
Потому что MCP сам по себе моделью не является.
——
✌️ ПРО СА|🎓НСА 3.0