dotnet new mcpserver ya viene incluido en el SDK de .NET 11 Preview 4

Las notas de versión de .NET 11 Preview 4 incluyen una línea pequeña pero clave para quien envía servidores Model Context Protocol desde C#: la plantilla de proyecto mcpserver, antes disponible solo instalando Microsoft.McpServer.ProjectTemplates, ahora se distribuye como plantilla integrada en el SDK de .NET. dotnet new list la descubre sin ninguna instalación extra, y su servicing viaja con el stack de ASP.NET Core en lugar de un paquete NuGet aparte.

Qué cambia con un SDK de Preview 4

Hasta .NET 11 Preview 3 la receta para un servidor MCP nuevo era de dos pasos:

# Preview 3 and earlier
dotnet new install Microsoft.McpServer.ProjectTemplates
dotnet new mcpserver -o InventoryMcp

En una imagen de CI limpia o el primer checkout de un compañero, el paso dotnet new install era el que se rompía en silencio: tiraba de NuGet, tenía su propia cadencia, y la plantilla vivía en tu perfil de usuario, que no sobrevive a un devcontainer fresco.

Con Preview 4 (11.0.100-preview.4), el paso uno desaparece:

dotnet new mcpserver -o InventoryMcp
cd InventoryMcp
dotnet run

La plantilla queda versionada con la release del SDK, así que un pin de global.json a 11.0.100-preview.4 también fija la plantilla.

Qué obtienes de fábrica

dotnet new mcpserver --help expone las perillas que soporta la plantilla. Las dos que más importan:

dotnet new mcpserver --help

# Options:
#   -f, --framework <net11.0>            The target framework.
#   --transport <stdio|http>             MCP transport type. Default: stdio.
#   --aot                                Enable Native AOT publish.
#   --self-contained                     Enable self-contained publish.

Aquí viven dos elecciones reales:

• --transport stdio (por defecto) te da un host de consola que habla el protocolo por stdin/stdout. Es lo que lanzan Claude Code, Claude Desktop y VS Code cuando bifurcan un hijo MCP desde mcp.json. Respuesta correcta cuando el agente está en la misma máquina.
• --transport http te da un host de ASP.NET Core con el transporte Streamable HTTP mapeado. Tira de él cuando el servidor vive detrás de un ingress y lo comparten varios agentes.

El switch --aot cablea Native AOT publish desde el inicio: PublishAot=true en el .csproj, source generators compatibles con AOT para los bindings del protocolo, y la fontanería trim-safe de atributos en el registro de tools. Combinado con --self-contained, obtienes un ejecutable de archivo único que arranca en decenas de milisegundos, lo que importa para servidores stdio porque el agente los bifurca en cada sesión.

Un esqueleto mínimo stdio se ve así:

// Program.cs -- generated by dotnet new mcpserver --transport stdio
using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);

builder.Logging.AddConsole(o =>
{
    // stderr only -- stdout is the protocol channel
    o.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Echo the input back.")]
    public static string Echo(string message) => $"hello {message}";
}

El logging solo-a-stderr viene de fábrica, que es el mayor tropiezo de quienes empiezan: cualquier Console.WriteLine perdido en stdout corrompe el flujo JSON-RPC y el agente reporta un error de protocolo sin detalle útil.

Cómo encaja con un proyecto existente

Si ya tienes un servidor MCP montado a la vieja usanza (revisa el walkthrough más profundo en Cómo construir un servidor MCP a medida en C# sobre .NET 11), no hace falta migración. La plantilla integrada genera las mismas referencias al paquete ModelContextProtocol que la antigua. El cambio es puramente sobre cómo empiezan los proyectos nuevos.

Lo que vale la pena hacer hoy: pinear global.json a 11.0.100-preview.4, quitar la línea dotnet new install Microsoft.McpServer.ProjectTemplates de los docs de setup del equipo y del devcontainer, y ver desaparecer una pregunta de día de onboarding en Slack.