Loading today’s stories
Build1 distinct publisher3 min readPublished
Wrapping an ASP.NET Core API in the Model Context Protocol is a two-file job. The part that takes real time is deciding whose token reaches the backend, and whether the backend will accept the one you forward.
The Engineer · Build desk
build
MCP's roadmap fast-tracks five priorities and quietly queues everything else1 distinct publisher
build
MCP's 2026-07-28 revision relocates client capabilities from the handshake into every request1 distinct publisher
build
Kubernetes MCP servers hide the delete tool; hiding is not removing1 distinct publisher
build
MCP 2026-07-28 drops the `result` wrapper, and your unit tests will not notice1 distinct publisher
Compiled by The EngineerSomething wrong?How this is made
Discovery is the line worth reading twice. `MapMcp()` wires it up, and any compliant AI client can then enumerate your tools [7]. The first host snippet in the walkthrough registers no authentication and no authorization at all; `UseAuthentication`, `UseAuthorization` and `RequireAuthorization` appear later, in the section about tokens [18]. Run that intermediate state somewhere reachable and the tool inventory reads without a credential [2]. A tool inventory is your internal API restated in prose a model can act on [9].
The attribute text is load-bearing for a reason that has nothing to do with documentation. The model reads `[Description]` on the method and on each parameter to decide when to call and what to pass, and the author is blunt that vague descriptions produce hallucinated arguments [9]. The description is part of the wire contract, and it's the one piece of that contract no compiler ever checks.
Then the arithmetic the walkthrough sets up and does not finish. The MCP server validates bearer tokens against authority `login.t1tech.com` with audience `mcp-invoice-server` [14]. The backend lives at `api.internal.t1tech.com` and is described as unchanged and still JWT-secured [17]. The recommended flow lifts the incoming token off `HttpContext` and attaches it to the downstream call [15]. That token's audience is the MCP server, not the API. So one of two things has to happen: the backend accepts an audience it was never issued for, or something in the middle exchanges the token for one the backend will validate [1]. The published text stops at the constructor that injects `IHttpContextAccessor` [15], which is where the decision actually begins.
The whole host is four SDK calls [3], and the claim that this takes an afternoon [16] is fair for the adapter. It transfers to your shop under conditions worth naming. Your existing endpoints have to map to whole tasks a person would ask for, because `GetOpenInvoices` is one HTTP GET with a filter [10] and a tool that needs six chained calls is a different project. Your identity provider has to be able to mint or exchange tokens for a second audience. And the backend's audience validation has to be yours to change. An identity migration runs on a longer clock than an afternoon.
There is a second consequence in the resource-server model that the code does not show. Under the MCP Authorization spec, Protected Resource Metadata (RFC 9728) lets the client discover where to log in [13], and the client is the one that authenticates the human and holds the token [12]. The login step moves into Claude Desktop, Gemini or Cursor [4]. Your auth path now runs through software your users install and configure on their own machines, outside your security team's deployment control.
Ranked by verification strength, evidence, and original report placement.
A dev.to walkthrough presents itself as a production engineer's guide to wrapping an existing ASP.NET Core REST API with the Model Context Protocol without tearing out the existing JWT stack.
The author says the work started when a product manager sent a Slack message asking "Can I just ask Claude to pull the open invoices from our system?"
The author frames the problem as follows: the data and API already existed, but an LLM has no idea the /api/invoices?status=open endpoint exists, and even if it did it cannot read the OpenAPI spec or authenticate itself.
MCP is described as an open protocol that lets AI clients including Claude Desktop, Gemini and Cursor discover and call capabilities as "tools"; you do not rewrite the API, you stand up a thin MCP server that exposes selected endpoints as tools and forwards the calls.
The MCP server is described as a translator that speaks JSON-RPC to the model and plain HTTP to the existing API, so business logic never moves.
The host is built with AddMcpServer(), WithHttpTransport(), WithToolsFromAssembly() to discover [McpServerTool] methods, and app.MapMcp(), which exposes the /mcp endpoint and wires up discovery so any compliant AI client can enumerate the tools.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One byline, but the code is on the page
The snippets are the strongest thing here: you can read the host configuration, the tool class and the pass-through constructor and judge them yourself without trusting the author. Everything around them is unbacked — the co-maintenance of the C# SDK, the RFC 9728 discovery flow and the claim that vague descriptions produce hallucinated arguments all rest on a single dev.to post that cites no spec, no repository and no incident.
A package install in a demo project
The only thing anyone actually runs in this story is a NuGet package inside a new minimal project. The 'battle-tested in production' line describes the invoice API that already existed, not the MCP layer bolted onto it, and no version, deployment, client or user of the wrapper appears anywhere in the reporting.
"The entire host" hides the harder half
dev.to's own structure argues against its afternoon estimate. Four calls buy you a tool listing; the remaining length goes to the token problem, and even then the piece stops without saying whether the backend will accept a token stamped for mcp-invoice-server. Calling the first snippet complete is the overstatement that matters, because that snippet is the one a hurried reader ships.
No sponsor, but the byline is the product
There is nothing being sold: the recommendation points at a free package and standards-track authorization, and no vendor relationship is disclosed or implied. What does shade the writing is the genre — a personal developer-platform post earns its reach on confidence, and phrases like 'do this before security reviews it' and 'the spec's blessed path' are doing reputational work. The example hosts, login.t1tech.com and api.internal.t1tech.com, read like the author's own shop rather than a neutral placeholder.
Firm on the code, thin on the world around it
We are confident about what the snippets do, because they are printed and internally consistent, and confident that the two gaps we flag are real. We are not confident about anything requiring a second witness: whether the SDK claim is accurate, whether real clients complete the RFC 9728 handshake as described, or whether this arrangement survives contact with a backend that checks audiences.