AI applications are moving beyond simple chat interfaces. Modern AI agents increasingly need to interact with real applications, business data, APIs, files, and internal services.
That is where the Model Context Protocol (MCP) becomes useful.
MCP provides a standardized way for AI applications to connect with external tools and data sources. Instead of creating a different integration mechanism for every AI model or application, developers can expose capabilities through MCP servers and let compatible clients discover and use them.
For .NET developers, this becomes particularly interesting with the release of MCP C# SDK 2.0.
Microsoft announced version 2.0 of the official MCP C# SDK on July 28, 2026. The release implements the July 28, 2026 revision of the MCP specification and introduces major changes around stateless HTTP, standardized HTTP headers, and Multi Round-Trip Requests.
In this article, we'll look at what MCP is, what's new in MCP C# SDK 2.0, how to build an MCP server with ASP.NET Core, and how MCP can be used in a real-world inventory management system.
The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications communicate with external tools, resources, and data sources.
A simple MCP architecture looks like this:
facebook
linkedin
instagram
twitter
AI Application / Agent
↓
MCP Client
↓
MCP Server
↓
Business Logic / APIs / Data
An MCP server can expose capabilities such as:
Get customer information
Search products
Check inventory
Query business reports
Create an order
Read documents
Call an internal API
Perform a controlled business operation
Microsoft's .NET documentation describes MCP as a client-server architecture where an AI host can connect to multiple MCP servers through MCP clients. MCP servers can provide abstractions over APIs, business logic, databases, files, and other resources.
This is different from giving an AI model direct access to your database.
Instead of:
AI
↓
PostgreSQL
you can build:
AI Agent
↓
MCP
↓
Application Service
↓
Repository
↓
PostgreSQL
This separation is especially important for business applications.
The MCP C# SDK is the official .NET implementation for building MCP clients and servers with C#.
It allows .NET developers to expose application capabilities as MCP tools and connect AI applications to those capabilities.
Microsoft maintains the SDK in collaboration with the MCP ecosystem, and it is available through NuGet.
The 2.0 release is particularly important because it aligns the SDK with the July 28, 2026 MCP specification revision.
According to Microsoft's announcement, the major changes include:
Stateless HTTP by default
Standardized HTTP headers
Multi Round-Trip Requests
Better support for horizontal scaling
Backward compatibility with existing stable v1 code
Redesigned Tasks extension
Separate optional packages for Tasks and Apps
One of the biggest changes in MCP C# SDK 2.0 is that HTTP transport is now stateless by default.
In previous versions, MCP HTTP communication could rely on sessions. The server returned an Mcp-Session-Id, and subsequent requests used that session identifier.
That approach can create additional complexity when an application runs across multiple servers.
For example:
Load Balancer
↓
┌──────────┼──────────┐
↓ ↓ ↓
Server 1 Server 2 Server 3
If session state is tied to a particular server, routing requests correctly can become more complicated.
With the new stateless approach, requests can be handled independently.
The MCP C# SDK 2.0 sets:
HttpServerTransportOptions.Stateless = true
by default.
This makes MCP applications easier to deploy in environments involving:
Multiple application instances
Cloud load balancers
Serverless workloads
Containers
Edge deployments
Auto-scaling infrastructure
Microsoft notes that stateful sessions are still available when an application genuinely needs session-scoped transport state or unsolicited server-to-client communication.
The new MCP specification also standardizes HTTP headers for MCP traffic.
For example, a tool request can expose information such as:
Mcp-Method: tools/call
Mcp-Name: get_product
Tool parameters can also be promoted to headers when appropriate.
Why does this matter?
Because infrastructure such as:
Load balancers
API gateways
Reverse proxies
WAFs
Monitoring systems
Observability tools
can understand important MCP request information without having to inspect the entire JSON-RPC body.
The request body remains authoritative. If the HTTP headers and body disagree, the server rejects the request instead of trying to guess which value is correct.
For ASP.NET Core developers, this fits naturally with the existing HTTP pipeline.
Another important addition is Multi Round-Trip Requests, commonly abbreviated as MRTR.
Some tools need additional information before they can complete an operation.
For example, imagine an AI agent asks:
Close support ticket #1234
The server may require a reason:
Why should the ticket be closed?
Previously, interactive workflows could depend heavily on session-based communication.
With MRTR, the server can return an InputRequiredResult.
The flow becomes:
AI Agent
↓
Call Tool
↓
MCP Server
↓
Input Required
↓
AI/User provides information
↓
Same Tool Called Again
↓
MCP Server
↓
Final Result
The request can carry an opaque requestState, allowing the server and client to continue the operation without requiring a long-lived transport session.
Microsoft describes MRTR as a major part of the July 28, 2026 specification revision.
This is useful for tools that require:
User confirmation
Additional parameters
Elicitation
Sampling
Roots information
Multi-step interactions
A major concern with any major SDK version is compatibility.
MCP C# SDK 2.0 is designed to preserve compatibility with existing stable v1 code.
According to Microsoft, stable non-deprecated 1.x APIs continue to compile and run in version 2.0. Older clients and servers can also communicate with newer implementations through compatibility behavior.
There is one important exception: the redesigned Tasks extension is not wire-compatible with the experimental Tasks implementation from v1.
So if you previously experimented with MCP Tasks, that part of your application should be reviewed before upgrading.
For an ASP.NET Core application, the MCP server can expose application functionality as tools.
For example, you might have an MCP tool called:
get_product
The tool could receive a product identifier and return information about that product.
A simplified concept looks like this:
[McpServerTool]
public async Task<ProductDto?> GetProduct(int productId)
{
return await productService.GetByIdAsync(productId);
}
The exact implementation depends on your SDK version and application architecture, but the important idea is that the MCP tool should normally call your existing application services rather than directly manipulating the database.
A healthy architecture is:
MCP Tool
↓
Application Service
↓
Domain / Business Rules
↓
Repository
↓
Database
This keeps the MCP layer focused on AI integration instead of turning it into another business-logic layer.
This is where MCP becomes particularly interesting for developers building business software.
Imagine an inventory management application built with:
ASP.NET Core
C#
Entity Framework Core
PostgreSQL
Blazor
Application services
Repository pattern
Instead of allowing an AI agent to directly access PostgreSQL, expose selected inventory capabilities through MCP.
The architecture could look like this:
AI Agent
↓
MCP C# SDK 2.0
↓
MCP Server
↓
Inventory Application
Services
↓
Repository
↓
PostgreSQL
Suppose the system exposes these MCP tools:
get_product
get_stock
get_sales_summary
create_purchase_order
The AI can then interact with the application using controlled operations.
A user might ask:
"How many units of iPhone 15 are currently in stock?"
The AI agent can determine that it needs the inventory tool:
get_stock(productName: "iPhone 15")
The MCP server receives the request and calls the existing application service:
MCP Tool
↓
InventoryService.GetStockAsync()
↓
StockRepository
↓
PostgreSQL
The database remains behind the application boundary.
The AI receives only the information it needs.
For example:
{
"product": "iPhone 15",
"availableStock": 27,
"reservedStock": 3
}
The AI can then turn that structured result into a natural-language answer.
A business owner could ask:
"How many units of Product X did we sell this month?"
The AI could call:
get_sales_summary(
productId: 1001,
startDate: "2026-09-01",
endDate: "2026-09-30"
)
The tool should not construct arbitrary SQL from the AI-generated request.
Instead:
MCP
↓
SalesService
↓
SalesRepository
↓
PostgreSQL
The existing application service can enforce business rules, permissions, date handling, tenant isolation, and other application requirements.
This is one of the biggest practical benefits of using MCP with an existing business application.
MCP becomes more sensitive when the AI is allowed to perform write operations.
Suppose a user says:
"Create a purchase order for 50 units of Product X."
A tool might be exposed as:
create_purchase_order
But the operation should not simply execute a database insert.
A safer flow is:
AI Agent
↓
MCP Tool
↓
Authentication
↓
Authorization
↓
Validate Product
↓
Validate Supplier
↓
Validate Quantity
↓
Business Rules
↓
Create Purchase Order
↓
Database
The MCP layer acts as a controlled interface to the application.
This approach also makes it easier to introduce approval workflows.
For example:
AI requests purchase order
↓
Validation
↓
Approval required
↓
User confirms
↓
Purchase order created
MRTR can be useful for interactive operations where additional input or confirmation is required.
Not all MCP tools should have the same level of access.
For an inventory application, you might classify tools like this:
| MCP Tool | Operation | Access |
|---|---|---|
get_product | Read | Normal user |
get_stock | Read | Normal user |
get_sales_summary | Read | Authorized user |
get_purchase_history | Read | Authorized user |
create_purchase_order | Write | Manager |
update_product_price | Write | Admin/Manager |
delete_product | Destructive | Admin |
This distinction is important because AI agents can potentially perform actions on behalf of users.
The MCP server should therefore respect the same authorization model as the rest of the application.
A common temptation when building an AI-enabled business application is to give the AI direct database access.
For example:
AI
↓
SQL Generator
↓
PostgreSQL
Although this can look simple, it creates several problems.
The AI could potentially:
Generate inefficient queries
Access data it should not see
Ignore business rules
Modify sensitive records
Access another tenant's data
Perform unintended operations
A controlled MCP architecture is different:
AI
↓
MCP
↓
Approved Tool
↓
Application Service
↓
Repository
↓
Database
The application remains responsible for business rules and data access.
For multi-tenant applications, this becomes even more important. Tenant identification and authorization should be enforced by trusted application code rather than relying on an AI-generated query.
The MCP C# SDK is designed to work with .NET applications, including ASP.NET Core.
For an HTTP-based MCP server, the ASP.NET Core integration package can be used:
dotnet add package ModelContextProtocol.AspNetCore
The SDK also provides core packages for lower-level MCP functionality.
Microsoft's current package structure includes packages such as:
ModelContextProtocol.Core
ModelContextProtocol
ModelContextProtocol.AspNetCore
ModelContextProtocol.Extensions.Tasks
ModelContextProtocol.Extensions.Apps
The exact package selection depends on whether you are building a server, client, or using optional extensions.
A typical application can therefore combine:
ASP.NET Core
+
MCP C# SDK
+
Existing Application Services
+
EF Core / Dapper
+
PostgreSQL / SQL Server
without rebuilding the entire application around MCP.
Some operations cannot complete immediately.
For example:
Generating a large report
Processing thousands of records
Running an expensive data analysis
Exporting a large dataset
Performing a long-running business operation
The MCP C# SDK 2.0 provides a redesigned Tasks extension for these scenarios.
Tasks are now available through a separate package:
ModelContextProtocol.Extensions.Tasks
This makes Tasks an opt-in capability instead of something every MCP application needs.
For a long-running operation, the conceptual flow can look like:
AI Agent
↓
Start Task
↓
Task ID
↓
Background Processing
↓
Poll Task
↓
Completed Result
For production environments, persistence becomes an important consideration, particularly when multiple application instances are involved.
MCP Apps are another extension supported separately from the base SDK.
The idea is to allow richer interactive experiences around MCP-enabled applications.
Because this functionality is optional and experimental, it should be evaluated separately rather than automatically adding it to every MCP project.
Keeping extensions separate helps developers use only the functionality their application actually needs.
MCP makes AI integration easier, but that also means security becomes extremely important.
An MCP server can potentially expose powerful business operations.
At minimum, consider:
Determine who is calling the MCP server.
Determine which tools the caller is allowed to use.
Never assume AI-generated parameters are safe or correct.
For example:
quantity = 500000
should not automatically become a valid purchase quantity simply because the AI requested it.
Protect expensive tools from excessive calls.
For business operations, record important actions such as:
User
Tool
Operation
Timestamp
Parameters
Result
Sensitive data should not be unnecessarily logged.
Only expose the tools an AI agent actually needs.
If an agent only needs to check stock, it should not automatically receive:
delete_product
or:
update_product_price
permissions.
The database should remain behind trusted application code.
This is especially important for applications containing financial, customer, inventory, healthcare, or other sensitive business data.
A REST API might already expose:
GET /api/products/1001
GET /api/products/1001/stock
GET /api/sales/summary
POST /api/purchase-orders
So why introduce MCP?
The difference is the interface intended for AI systems.
Traditional APIs are designed primarily for applications and developers.
MCP provides a standardized way for compatible AI applications and agents to discover and invoke capabilities.
You can therefore have:
Web App ──────→ REST API
Mobile App ───→ REST API
AI Agent ──────→ MCP
Both REST and MCP can ultimately use the same application services.
For example:
┌── REST API ──→ Application Service
Client ───────┤
└── MCP ───────→ Application Service
↓
Repository
↓
Database
This allows MCP to become another integration boundary instead of replacing the entire application architecture.
MCP becomes particularly powerful when combined with AI agents.
An AI agent may need to:
Understand a user's request
Select an appropriate tool
Call the MCP server
Receive structured data
Decide whether another tool is required
Perform additional operations
Return a final response
For example:
User
↓
AI Agent
↓
get_stock
↓
Analyze inventory
↓
get_sales_summary
↓
Compare demand
↓
AI Response
For an inventory application, the agent could potentially answer questions such as:
"Which products have low stock but strong sales this month?"
The agent could combine:
get_stock
+
get_sales_summary
without requiring a custom endpoint for every possible question.
The important point is that the AI is still operating through controlled tools.
MCP makes sense when your application needs AI to interact with external systems or business capabilities.
Good use cases include:
AI assistants
AI agents
Developer tools
Enterprise applications
Internal business assistants
CRM systems
ERP systems
Inventory applications
Financial applications
Documentation systems
Data analysis tools
MCP may be unnecessary if your application only needs a simple, tightly controlled AI API call.
For a small application with one AI operation, a normal API integration may be sufficient.
MCP becomes more attractive when you have multiple tools, multiple AI clients, or an ecosystem of AI-enabled applications.
If you already have an ASP.NET Core application, you don't need to rewrite it.
A practical migration strategy is:
Find business capabilities that are already exposed through application services.
For example:
ProductService
InventoryService
SalesService
PurchaseService
Choose operations that provide meaningful value to an AI agent.
For example:
get_product
get_stock
get_sales_summary
Expose those operations through MCP.
Avoid duplicating business rules inside MCP tools.
Use:
MCP Tool
↓
Existing Service
instead of:
MCP Tool
↓
New Business Logic
Make sure MCP calls follow the same access-control rules as your application.
Especially for write operations.
Test both normal and unexpected AI-generated inputs.
MCP C# SDK 2.0 represents an important step for .NET developers building AI-enabled applications.
The biggest change is not simply another set of APIs. The new MCP specification changes how MCP works over HTTP.
With stateless HTTP by default, MCP becomes easier to deploy across multiple application instances. Standardized HTTP headers make MCP traffic easier for existing infrastructure to route and observe. Multi Round-Trip Requests provide a more flexible way to build interactive tools without depending on long-lived sessions.
For existing .NET applications, perhaps the most practical approach is not to rebuild everything around MCP.
Instead, start with the business capabilities you already have.
For example:
AI Agent
↓
MCP C# SDK 2.0
↓
MCP Tools
↓
Application Services
↓
Repository Layer
↓
PostgreSQL / SQL
An inventory system could expose tools such as:
get_product
get_stock
get_sales_summary
create_purchase_order
The AI can then interact with the application while the existing business logic, authorization, validation, and database architecture remain under the application's control.
That is where MCP becomes particularly useful for .NET developers: it can add an AI integration layer to an existing application without requiring the application to surrender control of its business logic.
If you're already building applications with ASP.NET Core, C#, EF Core, PostgreSQL, or other .NET technologies, MCP C# SDK 2.0 provides a practical path toward making those applications accessible to modern AI agents.
Contact us today to schedule a free, 20-minute call to learn how DotNet Expert Solutions can help you revolutionize the way your company conducts business.
About us
Comments 0