Microsoft `mcp`: подключаем серверы Model Context Protocol на C# в .NET 10

Сегодняшний GitHub Trending (C#, ежедневный) включает microsoft/mcp — репозиторий Microsoft по Model Context Protocol (MCP). Если вы строите внутренние инструменты на .NET 10 и хотите чёткую границу между LLM-клиентом и реальными системами (файлы, тикеты, базы данных, CI), MCP — это та форма, за которой стоит следить.

Источник: microsoft/mcp

Полезный сдвиг: инструменты становятся контрактом, а не разовой обвязкой

Большинство “AI-интеграций” начинаются как разовый связующий код: шаблоны промптов, пара HTTP-вызовов и растущая стопка “ещё один инструмент”. В тот момент, когда вам нужны надёжность, аудит или удобный сценарий локальной разработки, вам нужен контракт:

• обнаруживаемый набор инструментов,
• типизированные входы и выходы,
• предсказуемый транспорт,
• журналы, по которым можно рассуждать.

Именно к этому стремится MCP: к границе протокола, чтобы клиент и сервер могли развиваться независимо.

Форма крошечного MCP-сервера на C# (что вы реально будете писать)

Точная форма API зависит от выбранной C#-библиотеки MCP (и это всё ещё ранний этап). При этом форма сервера стабильна: определить инструменты, валидировать ввод, выполнить, вернуть структурированный вывод.

Вот минимальный пример в стиле C# 14 для .NET 10, демонстрирующий подход “сначала контракт”. Воспринимайте его как шаблон для формы ваших обработчиков.

using System.Text.Json;

public static class CiTools
{
    public static string GetBuildStatus(JsonElement args)
    {
        if (!args.TryGetProperty("pipeline", out var pipelineProp) || pipelineProp.ValueKind != JsonValueKind.String)
            throw new ArgumentException("Missing required string argument: pipeline");

        var pipeline = pipelineProp.GetString()!;

        // Replace with your real implementation (Azure DevOps, GitHub, Jenkins).
        var status = new
        {
            pipeline,
            state = "green",
            lastRunUtc = DateTimeOffset.UtcNow.AddMinutes(-7),
        };

        return JsonSerializer.Serialize(status);
    }
}

Важны не детали парсинга JSON. Важно вот что:

• Явная валидация ввода: с MCP легко забыть, что вы строите API. Относитесь к нему как к API.
• Нет неявного окружающего состояния: передавайте зависимости явно, логируйте всё.
• Структурированные результаты: возвращайте стабильные формы, а не строки, которые невозможно сравнить.

Куда это ложится в реальной кодовой базе .NET 10

Если вы внедряете MCP в продакшн, вас будут заботить те же вещи, что и в любом сервисе:

• Аутентификация: идентичность должен обеспечивать сервер, а не клиент.
• Минимальные привилегии: инструменты должны открывать как можно меньшую поверхность.
• Наблюдаемость: идентификаторы запросов, логи вызовов инструментов и метрики сбоев.
• Детерминизм: инструменты должны быть безопасны для повторного вызова и, где возможно, идемпотентны.

Если на этой неделе делать что-то одно: клонируйте репозиторий, пробегитесь по документации протокола и набросайте список из 5 инструментов, которые вы сейчас реализуете как “обвязку промптов”. Этого списка обычно достаточно, чтобы обосновать настоящую MCP-границу.

Ресурс: microsoft/mcp