MCP (Model Context Protocol) — протокол, позволяющий AI-клиентам взаимодействовать с внешними приложениями через набор явно описанных инструментов.
Для Laravel есть официальный пакет laravel/mcp, поэтому для создания собственного MCP-сервера не нужно самостоятельно реализовывать протокол и транспорт.
Посмотрим, как это работает, на простом примере блога.
Предположим, у нас есть обычное Laravel-приложение со статьями:
Post
├── title
├── content
├── status
└── published_at
Мы хотим дать AI возможность:
найти статьи
получить статью
создать черновик
опубликовать статью
Для этого предоставим приложению несколько MCP Tools.
Установка Laravel MCP
Устанавливаем пакет через Composer:
composer require laravel/mcp
Публикуем MCP routes:
php artisan vendor:publish --tag=ai-routes
После этого можно создать MCP-сервер:
php artisan make:mcp-server BlogServer
И зарегистрировать его:
use App\Mcp\Servers\BlogServer;
use Laravel\Mcp\Facades\Mcp;
Mcp::web('/mcp', BlogServer::class);
Теперь /mcp становится точкой входа для MCP-клиентов.
Создаём Tool
Основной примитив MCP для такого сценария — Tool.
Tool — операция, которую AI может вызвать с определёнными параметрами.
Например, предоставим возможность искать статьи:
search_posts
У инструмента может быть примерно такая логика:
class SearchPosts extends Tool
{
public function description(): string
{
return 'Search blog posts';
}
public function handle(Request $request): array
{
return Post::query()
->when(
$request->get('query'),
fn ($builder, $query) =>
$builder->where('title', 'like', "%{$query}%")
)
->limit(20)
->get()
->toArray();
}
}
После регистрации Tool становится доступен подключённому MCP-клиенту.
Теперь пользователь может написать:
Найди статьи про Laravel.
AI определит, что для выполнения запроса подходит search_posts, вызовет его и использует полученный результат для ответа.
Добавляем остальные возможности
Для нашего блога можно предоставить небольшой набор инструментов:
search_posts
get_post
create_post
update_post
publish_post
Например:
create_post
может принимать:
{
"title": "Laravel MCP",
"content": "...",
"status": "draft"
}
А:
publish_post
только идентификатор статьи:
{
"post_id": 42
}
В результате AI получает не прямой доступ к базе данных, а ограниченный интерфейс приложения.
Это важное различие.
Мы сами определяем, что именно разрешено делать через MCP.
MCP как ещё один интерфейс приложения
Удобнее всего воспринимать MCP не как отдельную архитектуру, а как ещё один способ обратиться к существующему приложению.
У Laravel-проекта уже могут быть разные точки входа:
HTTP Controller ─┐
│
CLI Command ─────┼── Application Service
│
Queue Job ───────┤
│
MCP Tool ────────┘
MCP Tool в такой архитектуре играет примерно ту же роль, что HTTP-контроллер.
Он принимает входные параметры, проверяет доступ и вызывает существующую бизнес-логику.
Поэтому помещать всю логику непосредственно в Tool обычно не стоит.
Вместо:
class PublishPost extends Tool
{
public function handle(Request $request)
{
// много бизнес-логики
}
}
лучше использовать существующий сервис:
class PublishPost extends Tool
{
public function handle(Request $request)
{
return app(PostService::class)
->publish($request->get('post_id'));
}
}
Тогда одну операцию можно использовать из разных интерфейсов:
Web UI
REST API
CLI
MCP
Почему Tools лучше универсального API
Можно было бы создать один инструмент:
post_action
и передавать ему:
{
"action": "publish",
"post_id": 42
}
Но модели проще работать с небольшим набором явно описанных возможностей:
search_posts
get_post
create_post
update_post
publish_post
Каждый Tool имеет собственное описание и схему параметров.
По сути, набор Tools становится API, спроектированным специально для LLM.
При этом слишком сильно дробить операции тоже не стоит.
Например:
post_set_title
post_set_content
post_set_status
post_set_publish_date
скорее всего, будут избыточными.
Для этого достаточно одного:
update_post
Авторизация никуда не исчезает
Подключение AI не должно означать обход существующей системы доступа.
Если пользователь не может опубликовать статью через обычную админку, он не должен иметь возможности сделать это через MCP.
Схема остаётся привычной:
MCP Client
↓
Authentication
↓
Laravel User
↓
Policies / Gates
↓
Tool
↓
Application
Внутри Tool можно использовать стандартные механизмы Laravel:
Gate::authorize('publish', $post);
Таким образом MCP работает в рамках существующей модели безопасности приложения.
Что в итоге получает пользователь
После подключения MCP взаимодействие с блогом может выглядеть так:
Найди мои статьи про Laravel.
Затем:
Открой последнюю.
После этого:
Добавь в неё раздел про MCP.
И наконец:
Сохрани изменения как черновик.
Для выполнения этих команд модель может последовательно вызвать:
search_posts
↓
get_post
↓
update_post
Пользователю не обязательно знать структуру API или параметры конкретных запросов.
Он описывает желаемый результат, а модель выбирает подходящие инструменты.
Опасные действия
Для операций чтения:
search_posts
get_post
обычно достаточно обычной авторизации.
С изменениями стоит быть осторожнее:
update_post
delete_post
publish_post
Например, публикацию можно сделать двухэтапной:
AI вызывает prepare_publish
↓
пользователь видит изменения
↓
подтверждает
↓
статья публикуется
Это особенно полезно, когда MCP начинает использоваться не только для блога, но и для более серьёзных административных операций.
Tools, Resources и Prompts
Tools — не единственная возможность MCP.
Протокол также предусматривает Resources и Prompts.
Resources можно использовать для предоставления контекста:
post://42
category://laravel
Prompts — для готовых сценариев работы с моделью.
Но для интеграции AI с существующим CRUD-приложением именно Tools обычно являются самой очевидной отправной точкой.
С них вполне можно начать, а остальные возможности добавлять по мере необходимости.
MCP не заменяет REST API
MCP не обязательно должен заменять существующий API.
У них немного разные задачи.
REST API хорошо подходит для предсказуемого взаимодействия:
Frontend → Backend
Mobile → Backend
Service → Backend
MCP — для взаимодействия модели с приложением:
LLM → Backend
Поэтому они спокойно существуют одновременно:
REST ─────┐
│
CLI ──────┼── Application
│
MCP ──────┘
И используют одну бизнес-логику.
Где это может пригодиться
Блог — намеренно простой пример.
Та же схема применима практически к любой Laravel-системе.
Если в приложении уже существуют операции, которые можно выразить как:
найти
получить
создать
изменить
выполнить действие
часть из них можно предоставить AI через MCP.
При этом не нужно передавать модели полный доступ к приложению или придумывать специальный AI API.
Достаточно определить ограниченный набор возможностей.
Итог
Официальный laravel/mcp заметно снижает порог входа в MCP для Laravel-разработчиков.
Вместо реализации протокола можно сосредоточиться на действительно важной части — проектировании инструментов, которые мы хотим предоставить модели.
Архитектурно при этом ничего необычного не происходит:
MCP Tool
↓
Application Service
↓
Domain / Models
MCP становится ещё одним интерфейсом Laravel-приложения наряду с HTTP, CLI и очередями.
Только предназначен этот интерфейс не для браузера или другого сервиса, а для AI.
Добавить комментарий