DEV Community: Matt Anderson

Vibe Coding Is Not AI-Assisted Development (And Conflating Them Is Hurting Us Both)

Matt Anderson — Sun, 22 Mar 2026 14:04:29 +0000

There's a term doing the rounds right now that makes me twitch every time I see it used interchangeably with something I actually care about: vibe coding.

I'm not here to gatekeep. Language evolves, terms get stretched, and honestly, if vibe coding gets more people writing software, that's probably net positive for the world. But I am here to argue that conflating vibe coding with AI-assisted development is quietly doing damage — to how teams evaluate tooling, to how organisations set expectations, and to how we as engineers think about our own craft.

These are not the same thing. They are not even on the same spectrum.

What Vibe Coding Actually Is

Karpathy coined the term earlier this year, and to his credit, he was honest about what it meant. You describe what you want, you accept what the model gives you, you don't particularly read it, and you move on. You're surfing a wave of plausible output. The vibe is the product.

This is a genuinely interesting mode of working. For prototyping, for throwaway scripts, for people who would never have written code at all — it unlocks things. I have zero contempt for it.

But notice what it isn't: it isn't a developer using AI to do their job better. It's a person using AI instead of developing. The distinction sounds pedantic until you ask the obvious follow-up question: who is responsible for what ships?

In vibe coding, the answer is murky by design. You're not making engineering decisions. You're making prompting decisions, which is a different skill with a different risk profile.

What AI-Assisted Development Actually Is

AI-assisted development is what happens when a working software engineer uses AI tooling to operate at a higher level of abstraction without surrendering ownership of the output.

You're still reading the code. You're still reasoning about the architecture. You're still the person who has to answer for the system's behaviour at 2am when it pages you. The AI is a force multiplier on your existing competence — not a replacement for it.

Think about what this looks like in practice:

You're designing an integration layer. You sketch the contract, you have the model draft the implementation, you read it critically, you push back on the bits that smell wrong, and you ship something you could rewrite from scratch if you had to.
You're writing tests for a complex interaction. You describe the scenario in plain language, the model produces a test skeleton, you recognise that the assertion is subtly wrong because you understand the domain, and you fix it.
You're reviewing a pull request. You use AI to summarise the diff and flag patterns, but you make the actual decision about whether the change is safe.

In each of these cases, the AI is doing work inside your engineering process, not replacing it. You are still the engineer.

Why the Conflation Is Harmful

When organisations can't tell these two things apart, predictable things start to go wrong.

Expectation misalignment. A team that's genuinely doing AI-assisted development — thinking hard, reviewing carefully, building maintainable systems — gets compared unfavourably to a team vibe-coding their way through a sprint at four times the velocity. Until the first production incident.

Hiring and skills atrophy. If vibe coding and AI-assisted development are the same thing, then foundational engineering knowledge stops mattering. Why understand how a database index works if the model can just write the query? This is a dangerous conclusion. The model's query is only as good as the engineer's ability to recognise a bad one.

Tooling evaluation gets muddled. The tools that make vibe coding productive (fast generation, high acceptance rate, minimal friction) are not the same tools that make AI-assisted development productive. A serious engineering team needs tools with good diff views, reliable context handling, testability, and tight feedback loops. Choosing tooling based on vibe-coding benchmarks is like choosing a scalpel based on how well it slices bread.

It flattens the skill curve. Vibe coding is low-floor, low-ceiling. AI-assisted development is low-floor, high-ceiling. When we treat them as equivalent, we lose the incentive to climb.

The Ownership Question

Here's the sharpest way I know to draw the line: who owns the output?

In vibe coding, the ownership is diffuse. If it breaks, you shrug and reprompt. This is fine when the stakes are low. It's a problem when the stakes aren't.

In AI-assisted development, the engineer owns the output. Fully. The fact that an LLM drafted the function doesn't change that. You reviewed it. You committed it. You deployed it. It's yours.

This isn't a philosophical point — it has practical consequences. Owning the output means you have to be able to reason about it. Which means you have to understand it. Which means the model's draft is the start of a conversation, not the end of one.

That's a fundamentally different relationship with the tool.

A Note on Ego

I want to be careful here, because there's a version of this argument that slides into elitism. "Real developers don't vibe code" is not what I'm saying. Plenty of vibe coding happens in professional contexts and produces genuinely useful things.

What I'm pushing back against is the industry narrative that AI has "democratised" software development in a way that makes the craft of engineering less relevant. It hasn't. It's lowered the floor, which is great. It has not lowered the ceiling, and it has not changed what's required to operate near it.

The engineers I respect most right now are the ones who've leaned into AI tooling hardest and maintained the strongest grip on what's actually happening in their systems. They're faster, they're more exploratory, they try more things. But they're still engineers.

Where This Leaves Us

If you're vibe coding, do it consciously. Know what you're trading. Keep it in the right contexts. Don't confuse velocity for quality.

If you're doing AI-assisted development, own the distinction. Push back when someone assumes you're just typing less. Explain why the review step isn't optional. Make the case for what you're actually doing.

And if you're in a position to set team or organisational standards — please, draw the line clearly. The tools available to us right now are extraordinary. But they reward engineers who understand them more than they reward engineers who simply use them.

The vibe is not the product. The product is the product. And someone has to be responsible for it.

I work on test automation tooling — frameworks, MCP servers, and the infrastructure that makes AI-assisted development actually testable. If you're thinking seriously about how AI fits into a professional engineering workflow, I'd love to hear how you're drawing these lines in the comments.

ASP.NET Core Devs: The MCP Spec Has Four Primitives. You've Only Been Using One.

Matt Anderson — Thu, 19 Mar 2026 21:07:15 +0000

When I shipped the first public version of ZeroMCP, it did one thing: expose controller actions as MCP tools via a single attribute and two lines of setup. That was enough to prove the model worked — in-process dispatch through your real ASP.NET Core pipeline, no second service, no duplicated logic.

1.5 fills out the rest of the MCP specification surface. Here's what's new.

Resources and Resource Templates

MCP distinguishes between tools (things clients can invoke) and resources (data clients can read at well-known URIs). ZeroMCP now supports both.

[HttpGet("system/status")]
[McpResource("system://status", "system_status",
    Description = "Current system status.",
    MimeType = "application/json")]
public IActionResult GetSystemStatus() => Ok(new { status = "ok" });

Resource templates extend this to parameterised URIs using RFC 6570 patterns:

[HttpGet("products/{id}")]
[McpTemplate("catalog://products/{id}", "product_resource",
    Description = "Returns a product by ID.",
    MimeType = "application/json")]
public IActionResult GetProduct(int id) => Ok(Store.Find(id));

Clients discover resources via resources/list and templates via resources/templates/list, then fetch content with resources/read. The dispatch model is identical to tools — the same synthetic HttpContext, the same pipeline, the same DI scope.

Both controller attributes and minimal API equivalents are supported:

app.MapGet("/api/status", () => Results.Ok(new { status = "ok" }))
   .AsResource("system://status", "system_status", "Current system status.");

Prompts

Prompts are reusable, parameterised prompt templates. Clients call prompts/list to discover them, then prompts/get with arguments to render the result.

[HttpGet("search")]
[McpPrompt("search_products",
    Description = "Search products by keyword and optional category.")]
public IActionResult SearchProducts([Required] string keyword, string? category = null)
    => Ok($"Search for '{keyword}' in category '{category ?? "all"}'.");

This is useful when you want to give LLM clients a structured way to construct prompts from your domain data, rather than hardcoding prompt text in the client.

Streaming via IAsyncEnumerable

Controller actions that return IAsyncEnumerable<T> are now automatically detected as streaming tools at registration time.

[HttpGet("stream")]
[Mcp("stream_orders", Description = "Streams all orders.")]
public async IAsyncEnumerable<Order> StreamOrders(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    foreach (var order in Store)
    {
        ct.ThrowIfCancellationRequested();
        await Task.Delay(250, ct);
        yield return order;
    }
}

Over Streamable HTTP, each item is sent as a Server-Sent Event. Over stdio, each chunk is a separate JSON-RPC response line. Streaming tools appear with "streaming": true in tools/list. A MaxStreamingItems safety cap (default 10,000) prevents runaway enumeration.

Notifications and Subscriptions

Two new opt-in capabilities handle the MCP notification model.

EnableListChangedNotifications causes ZeroMCP to advertise list change support during handshake and push notifications/tools/list_changed, notifications/resources/list_changed, and notifications/prompts/list_changed to connected SSE clients when you call the corresponding notify methods.

EnableResourceSubscriptions lets clients subscribe to specific resource URIs and receive targeted notifications/resources/updated events when content changes. The trigger side is yours to implement — call NotifyResourceUpdatedAsync(uri) from a controller, background service, or message handler:

await _notificationService.NotifyResourceUpdatedAsync("orders://order/42");

Tool Versioning

Tools can now be versioned, which lets you expose multiple versions of the same tool surface at distinct MCP endpoints.

[Mcp("get_order", Description = "v2 of get_order.", Version = 2)]

Without versioning, only /mcp is registered. With versioning, you get /mcp/v1, /mcp/v2, etc., with the unversioned /mcp resolving to the highest version. The Inspector UI gains a version selector and version badges when multiple versions exist.

This is primarily aimed at teams running phased client migrations where you can't update all consumers simultaneously.

Inspector UI

The Inspector was introduced in an earlier release as a JSON endpoint (GET /mcp/tools). 1.5 adds a browser-based invocation UI at GET /mcp/ui — think Swagger UI, but for your MCP tool surface.

From the UI you can browse tools, view their JSON Schema inputs, and invoke tools/call with editable arguments directly in the browser. Streaming tools render results progressively and show a badge indicating their type.

Both endpoints are enabled by default and should be disabled in production:

options.EnableToolInspector = builder.Environment.IsDevelopment();
options.EnableToolInspectorUI = builder.Environment.IsDevelopment();

stdio Transport

The HTTP transport is still the primary path, but 1.5 ships first-class stdio support for local and desktop MCP clients that spawn your process directly:

if (args.Contains("--mcp-stdio"))
{
    await app.RunMcpStdioAsync();
    return;
}
app.Run();

The Claude Desktop configuration looks like this:

{
  "mcpServers": {
    "my-api": {
      "command": "dotnet",
      "args": ["run", "--project", "MyApi", "--", "--mcp-stdio"]
    }
  }
}

Everything else — discovery, dispatch, auth forwarding, governance — works identically across transports.

What Hasn't Changed

The core model is unchanged. [Mcp] still goes on individual controller actions or minimal API endpoints. Dispatch still creates a fresh DI scope and a synthetic HttpContext routed through your real pipeline. Auth, validation, and filters still run as normal. The upgrade path from earlier versions is additive — existing tool configurations require no changes.

Get It

<PackageReference Include="ZeroMCP" Version="1.*" />

Repository, wiki, and examples: github.com/ZeroMcp/ZeroMCP.net

Testing Your MCP Server Like You Mean It

Matt Anderson — Wed, 11 Mar 2026 11:46:35 +0000

The final part of the ZeroMcp series. Part one covered exposing your ASP.NET Core API as an MCP server. Part two covered everything that's grown since. Part three covered ZeroMcp.Relay for any OpenAPI-backed API. This one closes the loop on the question you should be asking by now: how do I test all of this?

I should probably have led with this from the start: by trade, I'm a test automation architect who specialises in tooling. That's not incidental context — it's why ZeroMcp exists the way it does, a way to provide consistent endpoints without the "human error" factor.

When you spend a career building test infrastructure, a particular instinct gets hard-wired: you don't consider something done until you can verify it works and detect when it stops working. Every tool in the ZeroMcp ecosystem was built with that instinct operating in the background. The [Mcp] attribute runs your real pipeline so your real tests still pass. The Tool Inspector UI lets you execute tools and inspect results. Relay validates specs before it starts serving tools. But none of that answered the question that actually mattered to me: how do you write a test that proves your MCP server behaves correctly?

There's a version of MCP development where you spin up your server, open Claude Desktop, and manually chat at it to see if the tools work. That gets you pretty far early on. It doesn't get you a CI pipeline, regression protection, or any confidence that a schema change didn't silently break tool outputs.

TestKit is where the circle closes: ZeroMcp.TestKit.

The Architecture: Two Repos, One Design Decision

TestKit is split into two repositories, and that split is intentional and worth understanding before anything else.

ZeroMcp.TeskKitEngine is a standalone Rust binary called mcptest. It accepts JSON test definitions, connects to any MCP server, runs the tests, and produces structured JSON results. It knows nothing about .NET, xUnit, or any specific language. It validates MCP protocol correctness, JSON Schema compliance, determinism, error paths, and tool metadata — for any MCP server, regardless of what it's built with.

ZeroMcp.TestKit.dotnet is a fluent C# DSL that wraps the engine. You write tests in idiomatic .NET, the DSL serializes them to JSON, shells out to mcptest, and parses the results back. xUnit integration ([McpFact], [McpTheory], McpAssert) makes tests show up in Visual Studio Test Explorer just like any other test project.

The implication: mcptest is the correctness oracle. The .NET DSL is a convenient way to talk to it. If you're building MCP servers in Python or Go, the engine works for you too — the Rust binary is the portable part.

Your xUnit test project
        │
        ▼
ZeroMcp.TestKit (.NET DSL)
        │  serializes to JSON, shells out
        ▼
mcptest (Rust binary)
        │  speaks MCP protocol
        ▼
Your MCP server (any language, any transport)

Quick Start

using ZeroMcp.TestKit;

await McpTest
    .Server("http://localhost:8000/mcp")
    .Tool("search")
        .WithParams(new { query = "hello" })
        .ExpectSchemaMatch()
        .ExpectDeterministic()
    .RunAsync();

That's a complete test. It connects to your MCP server, calls the search tool with { "query": "hello" }, validates that the response conforms to the tool's declared JSON Schema, and asserts that calling it again produces the same result. If either check fails, RunAsync() throws McpTestException with the details.

Install:

Add ZeroMcp.TestKit and ZeroMcp.TestKit.Xunit via Nuget

The mcptest binary is resolved automatically — first from MCPTEST_PATH, then from the bin directory, then from NuGet native assets (runtimes/{rid}/native/mcptest), then from your system PATH. Most of the time you don't need to think about it.

The Fluent API

The builder is designed to read like a spec of what you expect:

await McpTest
    .Server("http://localhost:8000/mcp")
    .WithTimeout(TimeSpan.FromSeconds(30))
    .WithDeterminismRuns(5)
    .ValidateProtocol()
    .ValidateMetadata()
    .WithAutoErrorTests()
    .Tool("search")
        .WithParams(new { query = "hello" })
        .ExpectSchemaMatch()
        .ExpectDeterministic()
        .WithIgnorePaths("$.result.timestamp")
    .Tool("create_order")
        .WithParams(new { customerName = "Alice", product = "Widget", quantity = 2 })
        .ExpectSchemaMatch()
    .Tool("get_order")
        .WithParams(new { id = 999 })
        .ExpectError()
    .RunAsync();

A few things worth pulling out:

.ValidateProtocol() — checks the MCP handshake, session lifecycle, and JSON-RPC frame structure. This catches implementation bugs that work fine when an LLM is calling your tools but would fail with a strict client.

.ValidateMetadata() — checks that every tool has a name, description, and a valid inputSchema. This is the check that enforces the contract the LLM depends on. Missing descriptions and malformed schemas are silent failures from the LLM's perspective; it just works less well. This makes them loud.

.WithAutoErrorTests() — automatically generates two additional tests: calling an unknown tool name, and calling a real tool with malformed parameters. Both should return proper JSON-RPC error responses. Surprisingly many MCP server implementations fail one or both of these.

.ExpectDeterministic() with .WithIgnorePaths(...) — calls the tool multiple times (default 3, configurable with .WithDeterminismRuns()) and compares results. WithIgnorePaths takes JSONPath expressions for fields that are legitimately non-deterministic, like timestamps or request IDs. Everything else must match.

.ExpectError() / .ExpectErrorCode(long) — for testing your error paths explicitly. If get_order with a non-existent ID should return an error, test that it does.

xUnit Integration

Add ZeroMcp.TestKit.Xunit and your MCP tests sit alongside your existing test suite:

using ZeroMcp.TestKit;
using ZeroMcp.TestKit.Xunit;

public class OrdersToolTests
{
    [McpFact(DisplayName = "get_order returns valid schema")]
    public async Task GetOrderSchemaValid()
    {
        await McpTest
            .Server("http://localhost:5000/mcp")
            .Tool("get_order")
                .WithParams(new { id = 1 })
                .ExpectSchemaMatch()
            .RunAsync();
    }

    [McpFact(DisplayName = "get_order returns error for unknown id")]
    public async Task GetOrderNotFound()
    {
        await McpTest
            .Server("http://localhost:5000/mcp")
            .Tool("get_order")
                .WithParams(new { id = 99999 })
                .ExpectError()
            .RunAsync();
    }

    [McpFact(DisplayName = "create_order is deterministic for same input")]
    public async Task CreateOrderDeterministic()
    {
        await McpTest
            .Server("http://localhost:5000/mcp")
            .WithDeterminismRuns(3)
            .Tool("create_order")
                .WithParams(new { customerName = "Alice", product = "Widget", quantity = 1 })
                .ExpectSchemaMatch()
                .ExpectDeterministic()
                .WithIgnorePaths("$.result.orderId", "$.result.createdAt")
            .RunAsync();
    }
}

[McpFact] is xUnit's [Fact] with DisplayName support tuned for MCP test naming. Tests appear in Test Explorer, run in CI with dotnet test, and fail with clear messages when something breaks.

For cases where you want assertion-style checks rather than throw-on-failure:

var result = await McpTest
    .Server("http://localhost:5000/mcp")
    .Tool("search").WithParams(new { query = "hello" }).ExpectSchemaMatch()
    .RunWithoutThrowAsync();

McpAssert.Passed(result);
McpAssert.ToolPassed(result, "search");
McpAssert.SchemaValid(result, "search");
McpAssert.Deterministic(result, "search");

What the Engine Actually Validates

It's worth being explicit about what mcptest checks, because some of these aren't things you'd think to test manually.

Protocol validation goes beyond "does it respond to tool calls." It checks the initialize / initialized handshake sequence, that JSON-RPC frames have correct id, method, and jsonrpc fields, and that error responses use the right error code structure. An MCP server that works with Claude but fails with a strict client — or a future version of the protocol — will show up here.

Schema validation checks that tool outputs conform to the tool's declared inputSchema. This is the contract your LLM depends on to understand what a tool returns. Schema drift — where the actual response shape diverges from what the tool advertises — is a silent regression. Your LLM starts hallucinating about what fields exist. This test catches that drift at the schema level before it manifests as confusing model behavior.

Determinism validation is about the LLM's ability to reason reliably about tool results. If calling get_order with the same ID returns different shapes on different calls, the model can't build a coherent mental model of what the tool does. This matters most for read-heavy tools that query live data — you exclude the volatile fields with WithIgnorePaths and validate that the structure itself is stable.

Baseline diffing — available via the mcptest diff command — lets you capture a known-good response and compare future runs against it. This is the regression detection story: after a deployment, run mcptest diff against your baselines and get a clear diff of anything that changed.

Recording and Replay

One practical feature for CI: session recording.

mcptest run --file tests.json --server http://localhost:8000/mcp --record session.json

Then replay offline, without a running server:

mcptest run --file tests.json --replay session.json

This matters for a few scenarios. If your MCP server connects to external APIs (via ZeroMcp.Relay, for example), you don't want CI making real calls to Stripe on every push. Record a session against a real server once, commit session.json, replay it in CI. You get the same correctness checks without the external dependency or the cost.

It's also useful for debugging: record a session where something went wrong, then replay it as many times as you need to understand the failure.

Scaffolding Tests

If you're adding TestKit to an existing MCP server, you don't have to write test definitions from scratch:

# Generate stubs for all tools
mcptest generate --scaffold --server http://localhost:8000/mcp --out tests.json

# Generate known-good baselines from real responses
mcptest generate --known-good --server http://localhost:8000/mcp \
  --params search:'{"query":"hello"}' --out baseline.json

--scaffold gives you a test definition with every tool stubbed out and placeholders for params. Fill in real values and you have a starting point. --known-good actually calls the tools and captures the responses as approved baselines — commit those and you have regression detection from day one.

ZeroMcp Integration

If you're using ZeroMcp (the library) for your own ASP.NET Core API, the natural pattern is to start the test host in-process and point TestKit at it:

public class McpToolIntegrationTests : IAsyncLifetime
{
    private WebApplication _app = null!;
    private string _serverUrl = null!;

    public async Task InitializeAsync()
    {
        var builder = WebApplication.CreateBuilder();
        builder.Services.AddControllers();
        builder.Services.AddEndpointsApiExplorer();
        builder.Services.AddZeroMcp(o => { o.ServerName = "Test"; o.ServerVersion = "1.0"; });
        // register your real services here

        _app = builder.Build();
        _app.MapControllers();
        _app.MapZeroMcp();

        var port = GetFreePort();
        _serverUrl = $"http://localhost:{port}";
        await _app.StartAsync();
    }

    [McpFact(DisplayName = "get_order tool schema is valid")]
    public async Task GetOrderSchemaValid()
    {
        await McpTest
            .Server($"{_serverUrl}/mcp")
            .ValidateMetadata()
            .Tool("get_order")
                .WithParams(new { id = 1 })
                .ExpectSchemaMatch()
            .RunAsync();
    }

    public async Task DisposeAsync() => await _app.StopAsync();
}

Your real DI container, your real services, your real pipeline — TestKit drives it through the MCP protocol the same way Claude would. The difference is you control the assertions.

The Thing This Solves

The honest version of MCP development without a test harness looks like this: you make a change, restart your server, open Claude, describe what you want it to do, and see if the tool call works. If it doesn't, you're reading logs and guessing. If it does, you ship. Then something breaks in production because a response shape changed and the model started interpreting a field that no longer exists.

TestKit is the thing that makes MCP tools first-class citizens of your existing software engineering practices. Schema validation catches drift before deployment. Determinism checks catch flakiness before the LLM notices it. Protocol validation catches spec violations before a client upgrade exposes them. Baseline diffing catches regressions in CI before they reach users.

None of this is exotic. It's the same category of testing you already do for your HTTP endpoints — just expressed in terms of what an MCP client expects rather than what an HTTP client expects.

And honestly, for me, it's also the inevitable destination. You don't spend a career building test infrastructure without developing a strong opinion that tooling without a test harness is a prototype, not a product. Every design decision across ZeroMcp — running the real pipeline, forwarding real headers, enforcing real auth — was made so that the things you'd want to test would be worth testing. TestKit is what makes that true. It's not the last piece bolted on; it's the piece the rest of the ecosystem was always pointing toward.

Get Started

Engine: github.com/ZeroMcp/ZeroMcp.TeskKitEngine
NuGet (core): dotnet add package ZeroMcp.TestKit
NuGet (xUnit): dotnet add package ZeroMcp.TestKit.Xunit
.NET DSL: github.com/ZeroMcp/ZeroMcp.TestKit.dotnet

Both repos are early, and I am looking at putting together DSL packages for Python, Rust and Node. Issues and PRs welcome — the MCP testing ecosystem for .NET is a blank slate and there's a lot of ground to cover.

Drop me a comment below if you do try it, and let me know how you get on

Turn Any OpenAPI Spec into an MCP Server with One Command (or how I used other people's APIs as a personal MCP)

Matt Anderson — Mon, 09 Mar 2026 23:00:23 +0000

Part three of the ZeroMcp series. Part one covered exposing your own ASP.NET Core API as an MCP server. Part two covered everything that's grown since then. This one is about a different problem entirely.

ZeroMcp started with a specific premise: you have an ASP.NET Core API, and you want AI clients to use it without rewriting anything. Slap [Mcp] on your controller actions, add two lines of setup, done.

But what about APIs you don't own?

What about Stripe, GitHub, your internal CRM, a third-party logistics API, a partner's REST service? You have credentials, you have documentation, maybe you have an OpenAPI spec URL — but you don't have source code to decorate with attributes.

That's the problem ZeroMcp.Relay solves.

What It Is

ZeroMcp.Relay is a standalone dotnet tool. You install it globally, point it at one or more OpenAPI spec URLs, configure authentication, and it immediately starts serving those APIs as MCP tools — no code, no compilation, no framework knowledge required.

dotnet tool install -g ZeroMcp.Relay

The command is mcprelay. The concept is simple: ingest a spec, generate tools, relay calls.

The two tools in the ZeroMcp ecosystem cover complementary territory:

ZeroMcp          ← your own ASP.NET Core APIs (in-process, NuGet package)
ZeroMcp.Relay    ← any API with an OpenAPI spec (outbound HTTP relay, dotnet tool)

They speak the same MCP protocol and can be used side-by-side.

Quick Start

# 1. Scaffold a config file
mcprelay configure init

# 2. Add an API
mcprelay configure add -n petstore \
  -s https://petstore3.swagger.io/api/v3/openapi.json

# 3. Run with the visual UI for setup
mcprelay run --enable-ui
# → open http://localhost:5000/ui

# 4. Or run headless for production
mcprelay run

# 5. Or run in stdio mode for Claude Desktop
mcprelay run --stdio

That's the whole workflow. Three commands from nothing to a working MCP server over any documented API.

The Config File

Everything lives in relay.config.json. Here's a realistic multi-API setup:

{
  "$schema": "https://zeromcp.dev/schemas/relay.config.json",
  "serverName": "My API Relay",
  "serverVersion": "1.0.0",
  "apis": [
    {
      "name": "stripe",
      "source": "https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json",
      "prefix": "stripe",
      "auth": {
        "type": "bearer",
        "token": "env:STRIPE_SECRET_KEY"
      },
      "exclude": ["test_helpers.*", "radar.*"]
    },
    {
      "name": "crm",
      "source": "https://internal-crm.company.com/swagger/v1/swagger.json",
      "prefix": "crm",
      "auth": {
        "type": "apikey",
        "header": "X-Api-Key",
        "value": "env:CRM_API_KEY"
      },
      "headers": {
        "X-Tenant-Id": "acme"
      }
    },
    {
      "name": "github",
      "source": "https://github.com/github/rest-api-description/raw/main/descriptions/api.github.com/api.github.com.json",
      "prefix": "gh",
      "auth": {
        "type": "bearer",
        "token": "env:GITHUB_TOKEN"
      }
    }
  ]
}

Notice env:STRIPE_SECRET_KEY — any credential value prefixed with env: is resolved from the environment at startup. If the variable isn't set, that API is disabled with a warning rather than starting with invalid credentials. You can also load a .env file:

mcprelay run --env .env.production

Authentication

Relay supports the auth patterns you'll actually encounter:

Bearer token — Authorization: Bearer {token} on every request.

API key (header) — any named header, e.g. X-Api-Key.

API key (query parameter) — appended to every URL, for APIs that expect ?api_key=....

HTTP Basic — Authorization: Basic {base64(user:pass)}.

None — for public APIs or internal services with network-level auth.

Per-API auth configuration means you can mix all of these in a single relay instance. Your Stripe integration uses bearer, your legacy internal API uses basic auth, your partner's API uses a query parameter — Relay handles each correctly without any cross-contamination.

How Tool Names Work

Tool names are {prefix}_{operationId}, lowercased, with non-alphanumeric characters replaced by underscores:

operationId: ChargeCreate  →  stripe_charge_create
operationId: GetCustomer   →  crm_get_customer

Operations without an operationId (which is unfortunately common) get a generated name from the HTTP method and path:

GET  /customers/{id}  →  crm_get_customers_id
POST /orders          →  crm_post_orders

The prefix is the key to multi-API sanity. When an LLM sees stripe_charge_create and crm_get_customer and gh_repos_list, it has an immediate signal about which system each tool belongs to. Duplicate prefixes cause a startup error — you can't accidentally collide two APIs' tool namespaces.

Include / Exclude Filtering

Real-world OpenAPI specs are big. Stripe's spec has hundreds of operations. GitHub's has over 500. You probably don't want to expose all of them as MCP tools — both because it's overwhelming for the LLM and because some operations shouldn't be accessible from an AI client at all.

Use glob patterns to control exactly what gets exposed:

{
  "name": "stripe",
  "include": ["stripe_charge_*", "stripe_customer_*", "stripe_invoice_*"],
  "exclude": ["stripe_*_test_*", "stripe_radar_*"]
}

include (if non-empty) is a whitelist. exclude then removes from whatever include allows. Both empty means all operations are included.

This is also where you enforce boundaries. An AI client probably shouldn't have access to your billing API's deletion endpoints, your admin reporting operations, or anything that touches test data. Exclude them at the Relay level and they don't exist as far as the LLM is concerned.

The Config UI

When you pass --enable-ui, Relay serves a visual interface at /ui for managing your configuration:

mcprelay run --enable-ui

The UI is deliberately opt-in and only available when explicitly enabled. A plain mcprelay run doesn't register the endpoint at all — not even a 404. This matters for production deployments where you don't want a management interface exposed.

The intended workflow is: use the UI during local setup to configure your APIs and get everything working, then run without --enable-ui in production.

What the UI gives you:

Adding a new API walks you through name, spec URL, auth, prefix, timeout, and include/exclude patterns. The standout feature is Fetch Spec: before you save, you can preview the spec — title, version, operation count, and any warnings (missing operationIds, malformed schemas, unresolvable $refs). You know exactly what you're getting before it's committed to config.

The tool browser lets you search and filter across all configured APIs, click into any tool to see its full input schema, and invoke tools directly from the UI — fill in arguments, hit execute, see the raw response. This is the same "Swagger UI for MCP" experience that the Tool Inspector brings to ZeroMcp proper, now available for externally-relayed APIs too.

Status indicators on the API list give you immediate visibility: green for loaded and healthy, yellow for disabled, red for spec fetch failure or missing auth credentials.

Two Modes: HTTP and stdio

HTTP Server Mode

The default. Relay starts an ASP.NET Core server and exposes:

POST /mcp          JSON-RPC 2.0 — MCP protocol
GET  /mcp          Server info
GET  /mcp/tools    Tool list JSON
GET  /health       Per-API status and tool counts

The health endpoint is worth highlighting:

{
  "status": "degraded",
  "apis": [
    { "name": "stripe",    "status": "ok",    "toolCount": 147 },
    { "name": "crm",       "status": "ok",    "toolCount": 34  },
    { "name": "logistics", "status": "error", "error": "Spec fetch failed" }
  ],
  "totalTools": 181
}

If one spec fails to load, the others keep working. degraded means some APIs are unavailable; error means all of them are. You can wire this into your existing health monitoring infrastructure — it's just an HTTP endpoint.

stdio Mode

Pass --stdio and Relay reads JSON-RPC from stdin and writes to stdout, with all logging going to stderr. This is what you use for Claude Desktop and Claude Code:

{
  "mcpServers": {
    "relay": {
      "command": "mcprelay",
      "args": ["run", "--stdio"],
      "env": {
        "STRIPE_SECRET_KEY": "sk_live_...",
        "CRM_API_KEY": "..."
      }
    }
  }
}

Or with a project-specific config:

{
  "mcpServers": {
    "relay": {
      "command": "mcprelay",
      "args": [
        "run", "--stdio",
        "--config", "/path/to/project/relay.config.json"
      ]
    }
  }
}

By default, all specs are fetched and validated before Relay starts reading from stdin. If you have many APIs and startup latency is a concern, --lazy defers spec fetching to the first tool call for each API.

CI Validation

One addition I'm particularly happy about: mcprelay validate.

mcprelay validate --strict --config relay.config.json

This fetches all spec URLs, parses them, resolves all environment variable references, and reports problems — missing operationIds, malformed schemas, unresolvable $refs, missing secrets. Exit code 0 on success, 1 on failure.

In a GitHub Actions workflow:

- name: Validate relay config
  run: mcprelay validate --strict --config relay.config.json
  env:
    STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}
    CRM_API_KEY: ${{ secrets.CRM_API_KEY }}

If someone accidentally commits a config pointing at a dead spec URL, or forgets to add a new secret to the CI environment, the pipeline catches it before deployment. This is the kind of thing that tends to get discovered at 2am in production otherwise.

Deployment

Local Developer (stdio)

The simplest path: install globally, point Claude Desktop at your local config.

dotnet tool install -g ZeroMcp.Relay
mcprelay configure init
mcprelay run --enable-ui   # set up your APIs visually
# then add to claude_desktop_config.json with --stdio

Team Server (HTTP)

Run Relay as a shared HTTP server your team's MCP clients connect to. Everyone gets the same API access without managing local credentials.

FROM mcr.microsoft.com/dotnet/runtime:9.0
RUN dotnet tool install -g ZeroMcp.Relay
ENV PATH="$PATH:/root/.dotnet/tools"
COPY relay.config.json /app/relay.config.json
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["mcprelay", "run", "--host", "0.0.0.0", "--port", "8080"]

docker run -p 8080:8080 \
  -e STRIPE_SECRET_KEY=sk_live_... \
  -e CRM_API_KEY=... \
  myrelay:latest

TLS termination goes in front of Relay (nginx, Caddy, Traefik — whatever you already use).

Filling the stdio Gap in ZeroMcp

There's one more use case for Relay that deserves its own callout, because it's not obvious at first: Relay in stdio mode is also the answer for your own ZeroMcp APIs when you need stdio.

ZeroMcp (the library) speaks Streamable HTTP only. That's intentional — it runs in-process inside your ASP.NET Core app and dispatches through your real pipeline. But it means Claude Desktop and Claude Code, which expect a stdio process, can't connect to it directly.

Relay closes that gap. Point Relay at your own app's /mcp endpoint — the one ZeroMcp exposes — and run Relay in stdio mode:

{
  "mcpServers": {
    "my-api": {
      "command": "mcprelay",
      "args": ["run", "--stdio"],
    }
  }
}

{
  "name": "my-api",
  "source": "http://localhost:5000/mcp/tools",
  "prefix": "myapi",
  "auth": {
    "type": "bearer",
    "token": "env:MY_API_KEY"
  }
}

Relay reads from ZeroMcp's tool inspector endpoint to get the spec, then proxies tool calls through to /mcp. Claude Desktop gets a stdio process; your app gets normal in-process dispatch through its full pipeline. Both sides are happy.

This makes the full picture:

Claude Desktop / Claude Code (stdio)
        │
        ▼
  mcprelay --stdio           ← ZeroMcp.Relay, reads JSON-RPC from stdin
        │
        │  HTTP  POST /mcp
        ▼
  Your ASP.NET Core app      ← ZeroMcp, in-process dispatch
        │
        ▼
  Your controllers / endpoints

The Bigger Picture

ZeroMcp.Relay and ZeroMcp proper solve adjacent but distinct problems — and Relay bridges the one gap ZeroMcp leaves open.

ZeroMcp is about your own APIs: your source code, your pipeline, your auth filters running in-process. The value is zero duplication and full fidelity to your existing implementation. Its constraint is transport: HTTP only.

ZeroMcp.Relay is about reach: any API with an OpenAPI spec, any transport. Third-party services, internal APIs you don't own, and — via the stdio bridge pattern above — your own ZeroMcp APIs when you need to connect a stdio client.

Together, they cover the full range. Build your internal capabilities with ZeroMcp. Connect to external services and stdio clients with ZeroMcp.Relay. Use both from the same MCP client.

Get Started

Install: dotnet tool install -g ZeroMcp.Relay
GitHub: github.com/ZeroMcp/ZeroMcp.Relay (latest: v0.1.1)
ZeroMcp (the library): github.com/ZeroMcp/ZeroMCP.net

This is early — v0.1.1 — and there will be rough edges, especially around OpenAPI specs that use unusual patterns or non-standard extensions. If something doesn't work, open an issue with the spec URL (or a minimal reproduction) and I'll take a look.

Tags: #mcp #dotnet #webdev #llm #openapi

ZeroMCP Has Grown Up: From a Single Attribute to a Production-Ready MCP Platform

Matt Anderson — Mon, 09 Mar 2026 19:11:22 +0000

A follow-up to "Your Existing ASP.NET Core API is Already an MCP Server — You Just Don't Know It Yet"

When I published the original ZeroMCP article a few weeks ago, the pitch was simple: tag a controller action with [Mcp], add two lines of setup, and your existing ASP.NET Core API becomes an MCP server. Zero duplication, zero new process, zero rewriting.

The response was encouraging — enough that I've kept building. And ZeroMCP has grown considerably since then.

This post is an honest look at what's changed: what got added, why, and what's coming next.

Where We Started

The v1.0 story was about the core insight: your controller pipeline is already doing exactly what an MCP server needs to do. Instead of duplicating it into a separate [McpServerTool] class (where your auth filters don't run, your ModelState doesn't validate, your DI scope is wrong), ZeroMCP dispatches through IActionInvokerFactory — the real pipeline — using a synthetic HttpContext built from the LLM's tool arguments.

That core mechanic hasn't changed. It's still the heart of everything.

What has changed is everything built on top of it.

Observability and Governance

The first thing that became obvious after dogfooding the library on real APIs: you need to be able to see what's happening.

Structured Logging

Every MCP request now emits structured log entries with a scope containing CorrelationId, JsonRpcId, and Method. Tool invocations log ToolName, StatusCode, IsError, DurationMs, and CorrelationId. If you're using Serilog or any structured logging provider, these show up as first-class fields — filterable, queryable, alertable.

Correlation IDs

Send X-Correlation-ID on the MCP request and ZeroMCP echoes it in the response, propagates it to the synthetic request's TraceIdentifier, and includes it in every log entry. If you don't send one, a GUID is generated. This sounds like a small thing but it makes debugging agentic workflows — where a single user action can trigger dozens of tool calls — dramatically easier.

OpenTelemetry

Set EnableOpenTelemetryEnrichment = true and ZeroMCP tags Activity.Current with mcp.tool, mcp.status_code, mcp.is_error, mcp.duration_ms, and mcp.correlation_id. Your existing OpenTelemetry pipeline picks it up automatically — no new instrumentation needed.

Pluggable Metrics

Implement IMcpMetricsSink and register it after AddZeroMcp():

public class MyMetricsSink : IMcpMetricsSink
{
    public void RecordToolInvocation(string toolName, int statusCode, bool isError, long durationMs)
    {
        // Push to Prometheus, Datadog, Application Insights — whatever you use
    }
}

The default is a no-op, so there's no overhead if you don't need it.

Role and Policy-Based Tool Visibility

Phase 1 also solidified the governance story. Tools can now be restricted by role or policy directly on the [Mcp] attribute:

[Mcp("admin_report", Description = "Runs admin report.", Roles = ["Admin"])]
public ActionResult<Report> GetAdminReport() { ... }

[Mcp("sensitive_export", Description = "Exports customer PII.", Policy = "RequireDataSteward")]
public ActionResult<ExportResult> ExportData() { ... }

Tools not visible to the current user don't appear in tools/list and are rejected if called directly. The LLM never knows they exist. And because this is built on ASP.NET Core's standard IAuthorizationService, your existing auth policies and role claims work without any ZeroMCP-specific configuration.

For discovery-time filtering (e.g. strip out internal tools in production), use ToolFilter:

options.ToolFilter = name => !name.StartsWith("internal_");

For per-request filtering (e.g. show beta tools only to beta users), use ToolVisibilityFilter:

options.ToolVisibilityFilter = (name, ctx) =>
    ctx.Request.Headers.TryGetValue("X-Beta-Features", out _) || !name.StartsWith("beta_");

Result Enrichment, Follow-Ups, and Streaming

I then focussed on about making the LLM smarter about what to do with tool results.

Result Enrichment

Enable EnableResultEnrichment = true and tool call results include metadata alongside the payload: statusCode, durationMs, correlationId, and optional hints. The LLM can use this to reason about whether a call succeeded, how long it took, and what to try next.

Suggested Follow-Ups

This is the feature I'm most excited about. Set EnableSuggestedFollowUps = true and implement SuggestedFollowUpsProvider to return a list of suggested next tools after each invocation:

options.SuggestedFollowUpsProvider = (toolName, result, ctx) => toolName switch
{
    "create_order" => ["get_order", "list_customer_orders"],
    "get_customer" => ["list_customer_orders", "update_customer"],
    _ => []
};

The LLM gets a suggestedFollowUps field in the result. Whether it uses them is up to the model, but in practice this significantly improves multi-step workflow completion — the model has a map of "what makes sense to do next" rather than having to infer it from the tool list alone.

Streaming Tool Results

For large results (think: export endpoints, report generation, search results), you can now stream:

options.EnableStreamingToolResults = true;
options.StreamingChunkSize = 4096;

Results are returned as chunks with chunkIndex and isFinal fields. MCP clients that support streaming can start processing immediately rather than waiting for the full payload.

XmlDoc support

If you use Swagger for your existing APIs, the chances are you have already crafted descriptions of your Methods. If you do not specify a description in your [MCP] attribute, ZeroMCP will extract the description from your XmlDoc comments.

Rich Tool Metadata

The [Mcp] attribute now supports Category, Examples, and Hints:

[Mcp(
    name: "create_order",
    Description = "Creates a new order and returns the created record.",
    Category = "orders",
    Examples = ["Create order for Alice, 2 Widgets", "New order: Bob, 1 Gadget, rush"],
    Hints = ["idempotent:false", "cost:low", "side-effect:write"]
)]

Examples give the LLM concrete demonstrations of how to use the tool. Hints are free-form AI-facing signals — use them however makes sense for your domain. Category helps with grouping in tool inspectors and future filtering features.

The Tool Inspector — Including a Full UI

ZeroMCP now ships a browser-based tool inspector UI at /{routePrefix}/tools/ui.

If you've used Swagger UI, you already know what this feels like. Navigate to /mcp/tools/ui in a browser and you get a visual interface listing every registered MCP tool — name, description, category, input schema, tags, required roles, examples. And like Swagger UI, you can execute tools directly from the browser: fill in the arguments, hit invoke, and see the result come back.

This is genuinely useful in ways the JSON endpoint alone isn't:

During development, you can verify your [Mcp] attributes were picked up correctly and that your schema looks right, without setting up a full MCP client
When debugging, you can reproduce a tool call the LLM made and inspect the response directly
When onboarding teammates, you can hand them a URL and say "here are all the things the AI can do with this API" — no tooling required on their end

The underlying JSON endpoint (GET {routePrefix}/tools) is still there for programmatic use:

{
  "serverName": "My Orders API",
  "serverVersion": "2.0.0",
  "protocolVersion": "2024-11-05",
  "toolCount": 12,
  "tools": [
    {
      "name": "create_order",
      "description": "Creates a new order and returns the created record.",
      "httpMethod": "POST",
      "route": "/api/orders",
      "category": "orders",
      "examples": ["Create order for Alice, 2 Widgets"],
      "inputSchema": { ... }
    }
  ]
}

Both the UI and the JSON endpoint are controlled by the same option:

options.EnableToolInspector = true;  // default; exposes /tools and /tools/ui

Disable it in production if your tool list is sensitive:

options.EnableToolInspector = false;

The analogy to Swagger UI is deliberate. Swagger solved a real discoverability problem for REST APIs — before it, you had to read source code or documentation to understand what an API could do. ZeroMCP's inspector solves the same problem for MCP tools: it makes your AI-facing API surface visible, browsable, and testable without an AI client in the loop.

Four Production-Ready Examples

The examples/ folder now ships four standalone projects that represent the range of real-world configurations:

Example	What It Shows
Minimal	One controller action, one minimal API, no auth — the fastest path to working
WithAuth	API-key auth, role-based tool visibility, `[Authorize]` filters
WithEnrichment	Result enrichment, suggested follow-ups, streaming
Enterprise	Auth + enrichment + observability + ToolFilter + ToolVisibilityFilter together

Run any of them with dotnet run from its folder. The Enterprise example is the reference implementation for production deployments — it shows how all the pieces fit together without being a contrived demo.

The Benchmark Suite

ZeroMCP now ships ZeroMCP.Benchmarks, a BenchmarkDotNet project that measures dispatch overhead, schema generation cost, and throughput at various tool counts. I'll publish numbers in a dedicated post, but the short version: the overhead of the synthetic HttpContext approach is negligible compared to the cost of a real HTTP round-trip, which is what you'd be paying if you separated your MCP server from your API.

What's Still Missing (And What's Next)

Being direct about current limitations:

stdio transport isn't fully supported. ZeroMCP does support stdio, you just need to run the API endpoint locally, which is usually out of scope for this kind of implementation. A standalone relay solution is currently being developed to handle this.

Minimal API parameter binding is limited. Route parameters work. Query and body binding on minimal APIs is constrained by what the route pattern exposes. Controller actions have full binding support.

The two highest-impact next additions are stdio transport support and richer minimal API parameter binding — both listed in the Contributing section if you want to take a swing at either.

The Bigger Picture

Something has shifted in how I think about this project since the original article.

ZeroMCP started as a brownfield story: you have an existing API, here's how to add MCP with minimal disruption. That's still true. But what's become clearer is that for greenfield APIs, designing with [Mcp] from the start changes how you think about your endpoints.

When your API endpoint is also an AI tool, you start writing descriptions that matter to a model, not just a human developer reading Swagger. You think about what "suggested follow-ups" make sense after each operation. You consider what hints help the model understand side effects and cost. You think about which tools should be visible to which roles — not just from an access control perspective, but from a task completion perspective.

That's a different design discipline, and I think it's a good one. APIs that are legible to AI agents tend to be better designed APIs in general: cleaner semantics, more explicit contracts, better documentation.

ZeroMCP is becoming a library for building that kind of API.

Get Started

NuGet: nuget.org/packages/ZeroMcp (latest: v1.3.0)
GitHub: github.com/ZeroMcp/ZeroMCP.net
Wiki: Full configuration reference and enterprise usage guide

If you're using ZeroMCP in a real project, I'd love to hear about it in the GitHub Discussions. And if something doesn't work, open an issue — the MCP ecosystem for .NET is still early, and the rough edges are worth fixing.

Tags: #mcp #aspdotnet #webdev #llm #dotnet

Your Existing ASP.NET Core API is Already an MCP Server — You Just Don't Know It Yet

Matt Anderson — Fri, 27 Feb 2026 00:52:48 +0000

If you've been following the AI tooling space lately, you've probably heard about MCP — the Model Context Protocol. It's the standard that lets AI clients like Claude connect to external tools and APIs. And if you're a .NET developer, you've probably also had the thought: "How do I expose my existing API as MCP tools without rewriting everything?"

The answer most tutorials give you looks something like this:

[McpServerToolType]
public class OrderTools
{
    private readonly OrderService _orders;

    public OrderTools(OrderService orders) => _orders = orders;

    [McpServerTool, Description("Retrieves a single order by ID.")]
    public async Task<Order> GetOrder(int id) => await _orders.GetByIdAsync(id);

    [McpServerTool, Description("Creates a new order.")]
    public async Task<Order> CreateOrder(string customerName, string product, int quantity)
        => await _orders.CreateAsync(customerName, product, quantity);
}

You're duplicating your controller logic. Your auth filters don't run. Your ModelState validation doesn't run. Your existing DI pipeline is bypassed. You're maintaining two surfaces for the same functionality.

There's a better way.

Introducing ZeroMCP

ZeroMCP is a .NET library that exposes your existing ASP.NET Core API as an MCP server with a single attribute and two lines of setup. No separate process. No code duplication. No rewriting.

Here's what it looks like:

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    [HttpGet("{id}")]
    [Mcp("get_order", Description = "Retrieves a single order by ID.")]
    public ActionResult<Order> GetOrder(int id) { ... }

    [HttpPost]
    [Mcp("create_order", Description = "Creates a new order.")]
    public ActionResult<Order> CreateOrder([FromBody] CreateOrderRequest request) { ... }

    [HttpDelete("{id}")]
    // No [Mcp] — invisible to MCP clients
    public IActionResult Delete(int id) { ... }
}

That's it. Your existing controller, your existing logic, your existing pipeline — now also an MCP server.

Quick Start

1. Install

<PackageReference Include="ZeroMcp" Version="1.*" />

2. Register services

builder.Services.AddZeroMcp(options =>
{
    options.ServerName = "My Orders API";
    options.ServerVersion = "1.0.0";
});

3. Map the endpoint

app.MapZeroMcp(); // registers GET and POST /mcp

4. Connect your MCP client

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "my-api": {
      "type": "http",
      "url": "http://localhost:5000/mcp"
    }
  }
}

That's the entire setup. Point Claude at your /mcp endpoint and it will see your tagged actions as tools.

Why This Approach Is Different

Your entire pipeline runs

When an MCP client calls one of your tools, ZeroMCP doesn't call your method directly. It creates a fresh DI scope, builds a synthetic HttpContext with the correct route values, query string, and body, and dispatches through IActionInvokerFactory — the same pipeline a real HTTP request uses.

This means:

[Authorize] works — auth filters run normally
ModelState validation works — validation errors return as proper MCP errors
Exception filters work — unhandled exceptions are caught and returned gracefully
Your DI services, repositories, and business logic are called as-is

Parameters are merged automatically

ZeroMCP merges route params, query params, and body properties into a single flat JSON Schema that the LLM fills in:

[HttpPatch("{id}/status")]
[Mcp("update_order_status", Description = "Updates an order's status.")]
public IActionResult UpdateStatus(int id, [FromBody] UpdateStatusRequest req) { ... }

public class UpdateStatusRequest
{
    [Required] public string Status { get; set; }
    public string? Reason { get; set; }
}

Produces this MCP input schema automatically:

{
  "type": "object",
  "properties": {
    "id":     { "type": "integer" },
    "status": { "type": "string" },
    "reason": { "type": "string" }
  },
  "required": ["id", "status"]
}

Minimal APIs are supported too

app.MapGet("/api/health", () => Results.Ok(new { status = "ok" }))
   .AsMcp("health_check", "Returns API health status.");

Built for Production

ZeroMCP isn't just a quick demo library. It ships with features that enterprise teams actually need.

Auth forwarding

builder.Services.AddZeroMcp(options =>
{
    options.ForwardHeaders = ["Authorization"];
});

Headers are copied from the MCP request to the synthetic dispatch request, so your existing JWT or API key auth just works.

Role and policy-based tool visibility

[Mcp("admin_report", Description = "Runs admin report.", Roles = ["Admin"])]
public ActionResult<Report> GetAdminReport() { ... }

Tools not visible to the current user won't appear in tools/list at all — and direct calls to hidden tools are also rejected.

Per-request tool filtering

options.ToolVisibilityFilter = (name, ctx) =>
    ctx.Request.Headers.TryGetValue("X-Beta-Features", out _) || !name.StartsWith("beta_");

Observability out of the box

Structured logging with correlation IDs, tool name, status code, and duration
OpenTelemetry enrichment via EnableOpenTelemetryEnrichment = true
Pluggable metrics sink via IMcpMetricsSink

The Brownfield Story

This is where ZeroMCP really shines. If you have a 5-year-old ASP.NET Core API with hundreds of endpoints, complex auth, custom filters, and business logic that's been battle-tested in production — you don't need to rewrite any of it to participate in the MCP ecosystem.

You add a NuGet package, two lines of setup, and [Mcp] attributes to whichever endpoints make sense to expose. Your existing tests still pass. Your existing auth still works. Your existing monitoring still fires.

That's the zero in ZeroMCP.

Get Started

NuGet: nuget.org/packages/ZeroMcp
GitHub: github.com/ZeroMcp/ZeroMCP.net

PRs and issues welcome. The MCP ecosystem for .NET is still early — if you try it and hit something that doesn't work, open an issue.

If you would like to discuss this more - raise a discussion on the GitHub, especially if you have further questions!!!