What is Nabu.NET?
Nabu.Mcp.AspNetCore turns existing ASP.NET Core controller actions and Minimal API route handlers into Model Context Protocol tools, so AI assistants and agents can call your API safely. It does not ask you to re-declare your endpoints, duplicate validation, or re-implement your security model.
A tool call is replayed as a real HTTP request through your application's own pipeline, so authentication, authorization policies, action filters, model binding, model validation, exception handlers and every other piece of middleware keep working exactly as they do today.
Pipeline replay, not reflection
Tool calls traverse the full ASP.NET Core middleware pipeline as synthetic HTTP requests — nothing that makes an action safe is bypassed.
Your security model, untouched
[Authorize], policies, roles, claims and custom filters run exactly as over HTTP. The test suite proves a 403 over HTTP is a tool error over MCP.
Per-caller tool visibility
tools/list can be tailored with your own authorization policies, so each caller sees only the tools it may actually invoke.
Schemas from your types
JSON schemas are generated from CLR types, data annotations and XML docs. A well-documented API produces a well-described tool set for free.
Controllers and Minimal APIs
[McpTool] on actions and controllers, .McpTool() on route handlers — the same machinery behind both.
Broad framework support
Multi-targets netstandard2.0, net8.0 and net10.0 — from ASP.NET Core 2.1 up to .NET 10, with an optional adapter for the official MCP C# SDK.
Why replay the pipeline?
The obvious way to bridge an API to MCP is to reflect over controllers and invoke action methods
directly. That approach quietly drops everything that makes an ASP.NET Core action safe:
[Authorize] is enforced by middleware and filters, not by the method body;
ModelState is populated by model binding; rate limiting, tenant resolution and exception
handling all live outside the method.
Nabu takes the other route. During startup it captures the fully built RequestDelegate
at the very front of the pipeline. To run a tool it constructs a synthetic HttpContext
for the target route — carrying the caller's identity, forwarded credentials, a fresh DI scope and a
JSON body built from the tool arguments — and pushes it through that captured pipeline.
Read more in Authentication & security.
60-second example
builder.Services.AddNabuMcp(options =>
{
options.ServerName = "my-api";
options.RequireAuthorization = true;
});
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.UseNabuMcp(); // serves MCP at /mcp
app.MapControllers();
app.Run();
Mark an action with [McpTool] and it appears in tools/list with a schema
generated from its parameters and XML documentation. See the full walkthrough in
Getting started.
Frequently asked questions
Does my authentication and authorization still work over MCP?
Yes. Every tool call runs through the application's own middleware pipeline, so
[Authorize], policies, filters and validation behave exactly as for a real HTTP request.
Details in Authentication & security.
Do I have to rewrite my API or duplicate validation?
No. Nabu reads the routing and binding metadata your API already declares and replays tool calls through the existing pipeline. There is nothing to re-declare and no second security model to maintain.
Which .NET versions are supported?
netstandard2.0 (ASP.NET Core 2.1/2.2), net8.0 and net10.0. See Target frameworks.
Can one endpoint be published as several tools?
Yes — apply [McpTool] repeatedly with different names, parameter subsets and pinned
constants. See One action, several tools.
Can Nabu use the official MCP C# SDK as the protocol layer?
Yes. The Nabu.Mcp.ModelContextProtocol package mounts the official SDK's Streamable
HTTP endpoint while Nabu answers tools/list and tools/call behind it.
See Using the official MCP SDK.