Why MCP servers?  LLMs are powerful—but they’re limited to what they can ‘see’. The Model Context Protocol (MCP) is an open protocol that standardizes how apps expose tools, resources, and prompts to AI clients so models can interact with real systems in a structured, discoverable way.  For .NET developers, this is especially useful because you can build MCP servers in C# using the official MCP C# SDK and run servers locally over stdio or remotely over HTTP.  MCP mental model (fast)  Host: The application that contains the AI experience (IDE/agent tool).  Client: The MCP-capable component inside the host that connects to servers.  Server: Your service that exposes tools/resources/prompts.  Choosing a transport: STDIO vs Streamable HTTP  STDIO (local): The client launches your server as a subprocess and communicates via stdin/stdout. Messages are newline-delimited JSON-RPC, and stdout must contain only protocol messages (logs must go to stderr).  Streamable HTTP (remote/scalable): Runs as an independent server reachable over HTTP. Validate the Origin header to reduce DNS rebinding risk and bind to localhost for local runs.  Part 1 — The fastest way: .NET 10 MCP Server Project Template  Microsoft provides a quickstart showing how to create a minimal MCP server using the .NET 10 SDK and the Microsoft.McpServer.ProjectTemplates template package.  This path is great for getting a working server quickly with correct wiring and sane defaults.  dotnet new install Microsoft.McpServer.ProjectTemplates Part 2 — Build a Minimal STDIO MCP Server (from scratch)  STDIO is ideal when your MCP server needs access to local machine resources and you want the simplest deployment path.  Below is a minimal server that uses Microsoft.Extensions.Hosting and exposes one tool (Echo).    Step A — Create project & add packages dotnet new console -n MyMcpServer cd MyMcpServer dotnet add package ModelContextProtocol dotnet add package Microsoft.Extensions.Hosting Note: Microsoft’s MCP server walkthrough shows the SDK approach using Microsoft.Extensions.Hosting and MCP server registration in the builder Step B — Program.cs (STDIO server + tool discovery) using Microsoft.Extensions.Hosting; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Logging; using ModelContextProtocol.Server; using System.ComponentModel; var builder = Host.CreateApplicationBuilder(args); // IMPORTANT: STDIO servers must keep stdout clean. // Route logs to stderr so they don't corrupt JSON-RPC output. builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace); builder.Services .AddMcpServer() .WithStdioServerTransport() .WithToolsFromAssembly(); await builder.Build().RunAsync(); [McpServerToolType] public static class EchoTools { [McpServerTool, Description("Echoes the message back to the client.")] public static string Echo([Description("Message to echo")] string message) => $"Hello from MCP (.NET 10): {message}"; } Why the stderr logging rule matters The MCP transport spec explicitly requires that in stdio, servers must not write non-protocol output to stdout; logs should go to stderr   Part 3 — Build a Remote MCP Server over Streamable HTTP (ASP.NET Core)  If you want a centrally hosted MCP server (team-wide tooling, enterprise integrations), use HTTP transport. MCP’s spec notes Streamable HTTP is the standard remote transport and includes security requirements like Origin validation. [modelconte...rotocol.io], [dometrain.com]Below is a minimal HTTP server exposing a demo Weather tool.  Step A — Create ASP.NET Core app & add MCP server support   dotnet new web -n MyHttpMcpServer cd MyHttpMcpServer dotnet add package ModelContextProtocol.AspNetCore Step B — Program.cs (HTTP MCP endpoint) using ModelContextProtocol.Server; using System.ComponentModel; var builder = WebApplication.CreateBuilder(args); builder.Services .AddMcpServer() .WithHttpTransport(options => { // Stateless mode is commonly recommended for simple remote servers // that don't need advanced server->client features. options.Stateless = true; }) .WithToolsFromAssembly(); var app = builder.Build(); // Exposes /mcp endpoint (or the configured MCP endpoint) app.MapMcp(); app.Run("http://localhost:3001"); [McpServerToolType] public static class WeatherTools { [McpServerTool, Description("Returns a sample weather status for a city.")] public static string GetWeather(string city) => $"Weather for {city}: Sunny (demo)"; } Security note (important): For Streamable HTTP, MCP recommends validating the Origin header to prevent DNS rebinding and binding locally to localhost when running locally   Part 4 — Coding standards & best practices for MCP servers  STDIO rule: stdout must be pure JSON-RPC Never log to stdout. Use stderr.  Standard: Configure logging to stderr as shown in the STDIO sample. Keep tools small + deterministic Tool methods should be short, validate input, and return structured outputs. Avoid tools that do “too much” (hard to reason about / secure). Validate inputs like public APIs Even though an LLM is “calling” the tool, treat it like an untrusted client: Validate required fields Constrain sizes Apply allowlists where possible Prefer “read-only” tools first Start with: search/read/query tools Then move to “write” tools with extra safety checks. Remote servers must follow transport security guidance Streamable HTTP transport includes security requirements like Origin validation to mitigate DNS rebinding risks Conclusion  .NET 10 makes it practical to build MCP servers using local STDIO transport for quick, secure local tooling, and Streamable HTTP for scalable, shared integrations.  Start with a small set of safe tools, add observability and security early, and expand capabilities over time. 

AI has moved past the hype cycle and into a decisive phase. Enterprises are no longer impressed by demos or prototypes. They want solutions that can plug into real systems, support real workflows, and deliver real business outcomes. And this is exactly where the conversation around AI agents has taken a serious turn. Enterprises want AI that works inside real systems, not just in demos, and we have successfully built and deployed agents that operate in Microsoft Teams and Copilot at production scale. Enterprises today are shifting rapidly from AI experimentation to full-scale deployment. Executives are no longer asking, “Can we use AI?” They are asking, “How do we integrate AI into our existing workflows, systems, and teams in a reliable and secure way?” This is where many organizations hit a wall. Building an intelligent agent in a lab is one thing. Deploying it inside Microsoft Teams, Microsoft Copilot, or enterprise applications at scale is an entirely different challenge. And that is exactly the journey our team has been leading. Over the past year, we have moved from early-stage proof of concepts to delivering fully production-ready AI agents that operate inside real enterprise environments. We have built agents using Microsoft Semantic Kernel, Microsoft Agent Framework, LangChain, and other orchestration tools. Through this work, we have seen how these technologies bridge the gap between AI capabilities and real business needs. Semantic Kernel continues to be a critical part of our architecture, providing the orchestration foundation needed for maintainability, scalability, and extensibility. 1. Why Semantic Kernel Is the Backbone of Enterprise AI Agent Development Semantic Kernel enables AI systems to work with enterprise applications without disruption. For agent-based systems, this orchestration layer is essential. Through our implementation work, we have seen how Semantic Kernel supports: Smooth integration with legacy and modern platforms Centralized orchestration logic for multi-agent workflows Plugin-based extensibility that accelerates development Production-ready governance and maintainability This means AI agents do not sit on the side as isolated tools. They become operational digital co-workers embedded in real systems. 2. Our Journey From POCs to Production-Ready AI Agents Most companies stop at experimentation. We continued through to full deployment. Below is a summary of what we have built. A. AI Agents Using Semantic Kernel, Microsoft Agent Framework, and LangChain We have delivered multi-agent ecosystems using: Microsoft Semantic Kernel as the orchestration layer Microsoft Agent Framework for standardized agent structure LangChain for reasoning and tool coordination Azure OpenAI and other LLM services for generative intelligence These agents now support tasks such as: Multi-step planning Task decomposition Enterprise data retrieval Knowledge reasoning API-driven action execution B. Taking AI Agents From Pilot to Production Scaling prototypes into production required addressing challenges such as: Security and identity governance Observability and monitoring Performance optimization Reliability of multi-agent workflows Plugin maintainability Integration with enterprise APIs Human validation checkpoints Today, our agents are supporting real business operations, not just test environments. C. Agents Integrated Directly Into Microsoft Teams and Microsoft Copilot One of our major achievements is building fully operational agents inside Microsoft Teams and Copilot using pro-code solutions. These agents: Support employees directly inside their daily collaboration tools Trigger workflows and gather insights Retrieve knowledge from enterprise repositories Generate summaries, reports, and recommendations Execute system-level tasks through plugins and connectors This approach ensures high adoption because employees do not need to change the way they work. D. Using Semantic Kernel as the Orchestration Layer for Long-Term Scalability To ensure consistent architecture, we use Semantic Kernel as the foundation for: Memory management Skill and plugin organization Planning capabilities Reusable workflows Integration patterns Model-agnostic orchestration This is what allows our solutions to evolve without complete rewrites. 3. The Business Value We Are Delivering With Enterprise AI Agents Based on our production deployments, AI agents are driving value in areas such as: IT Operations Incident classification Automated diagnosis Recommendation and remediation assistance Knowledge Management Conversational search across documents and systems Automated summarization Fast retrieval of organizational knowledge Workflow Automation Streamlining approval processes Triggering ERP and CRM actions Coordinating tasks between departments Employee Productivity Drafting documentation and reports Generating meeting summaries Automating repetitive daily tasks inside Teams These are not theoretical examples. These are use cases we have taken from pilot to production. Actionable Insights: How Enterprises Can Start Their Own Agent Journey 1. Begin With a Focused Use Case Select a workflow that is high-effort and well understood. Examples include knowledge retrieval, IT incident classification, or automated document creation. 2. Invest Early in a Plugin Strategy Plugins become reusable skills for every agent your organization builds. This creates long-term scalability. 3. Standardize on Semantic Kernel for Orchestration This provides consistency across agents and reduces complexity as the ecosystem grows. 4. Work With a Partner Who Has Delivered Production-Ready Agents Enterprise-grade AI requires expertise in: Agent frameworks AI orchestration Microsoft ecosystem integration Security and governance Production deployment disciplines Our team brings this end-to-end capability, from design to deployment to continuous improvement. Conclusion AI agents are quickly becoming a core part of enterprise operations. But real value comes only when these agents move from experimentation into production environments. By leveraging Microsoft Semantic Kernel, Microsoft Agent Framework, and LangChain, we have successfully built and deployed AI agents inside Microsoft Teams and Microsoft Copilot using pro-code, enterprise-ready architectures. These systems are already powering real workflows and supporting real users. The organizations that act now will gain a significant advantage. We are excited to help shape this next chapter in enterprise AI adoption. 4. Call-to-Action If your organization is exploring AI agents or preparing to move from prototypes to production, we would be glad to collaborate. Connect with us for more insights on enterprise AI, agent orchestration, and Microsoft-based digital transformation.