MCP (Model Context Protocol) — Python & .NET Implementation from Scratch and Benchmarks

Generated by Gemini 3

What is MCP?

This blog post will discuss MCP. Actually, I covered MCP in detail in my previous blog post. But to summarize briefly, thanks to MCP, you can access your system’s external resources. For example, you have a book automation application, and you say you want to add the book “The Fisherman and His Son by Zülfü Livaneli” to the LLM. The LLM cannot directly access your system and use the book adding API. Thanks to MCP, it understands which endpoint you want to make this request to and redirects the request to that tool. Therefore, the model receives the necessary response from your external resources without needing to know your system and can return a response to the user, such as “Your book has been successfully added.”

What Are We Building?

In our previous article, we built a RAG application that uses vector embeddings to retrieve relevant context and respond to user queries. Now we want to extend this pattern with tools — so the model can reach out to external resources and access real-time data when needed.

To demonstrate this, we’ll build MCP tools for a project management scenario. When a user asks “What is the active sprint?”, the model will call the get_sprint_status tool and return up-to-date information directly from the server.

Python vs. .NET Implementation

Tool Definition

Both Python and .NET use a similar approach — a decorator or attribute to mark a function as a tool, and a description to tell the LLM what it does. In Python, @mcp.tool() and a docstring are enough; FastMCP automatically generates the JSON schema. In .NET, [McpServerTool] and [Description] attributes do the same job.

[embed]

[embed]

Server Setup

The more notable difference is in how tools are discovered. In Python, you need to manually import each tool file in main.py — import tools.project_tools. Every time you add a new tool file, you have to remember to add the import. In .NET, WithToolsFromAssembly() scans the assembly and automatically picks up everything marked with [McpServerTool] — no manual imports needed. It’s not a major disadvantage on the Python side, but it’s worth noting: as the number of tools grows, the manual import step becomes an easy thing to forget.

[embed]

In .NET, WithToolsFromAssembly() scans the assembly and automatically picks up everything marked with [McpServerTool] — no manual imports needed. It’s not a major disadvantage on the Python side, but it’s worth noting: as the number of tools grows, the manual import step becomes an easy thing to forget.

[embed]

Both Python and .NET implement the MCP protocol — tool discovery, routing, and execution are handled by the framework in both cases. The key differences emerge in how tools are structured and how dependencies are managed.

Benchmark Results — A different kind of benchmark: lines of code

Performance isn’t the only metric worth comparing. I also looked at code volume — how much you actually have to write to build the same thing in each platform.

Cold Start — Python 0.071s vs .NET 3.021s: Python starts almost instantly. .NET takes ~3 seconds, but this includes the build step from dotnet run. With a published binary, startup drops below 200ms.

Total Lines — Python 219 vs .NET 298: .NET requires 36% more code — but almost all of it comes from the Models layer, explained below.

Entry Point — Python 6 vs .NET 18 lines: Python’s server.py + main.py is minimal. .NET's Program.cs includes DI registration, logging configuration, and MCP server setup.

Tool Definition — Python 59 vs .NET 64 lines: Nearly equal. The decorator vs attribute difference doesn’t meaningfully affect line count.

Business Logic — Python 154 vs .NET 170 lines: Similar structure, similar size. No real difference here.

Models — Python 0 vs .NET 46 lines: This is where the gap comes from. Python works with raw dicts — no model definitions needed. .NET requires explicit type declarations for SprintTask, Sprint, TeamMember, etc. This brings compile-time safety, but at the cost of 46 extra lines.

Takeaway: .NET requires more code, but it’s almost entirely the type system. Business logic is nearly identical across both platforms.

Conclusion

If you want to get things up and running quickly, work primarily in data science, or make heavy use of libraries like PyTorch and TensorFlow, Python is the natural choice. With a small team, a limited number of tools, and the need for a fast UI like Streamlit, Python offers significantly less friction.

If your team already works in .NET, the system is expected to grow, and long-term maintenance matters, .NET provides a much more solid foundation. Complex dependencies are managed automatically through the DI container. Errors are caught at compile time rather than at runtime — which becomes increasingly important as the codebase scales. And if you want to add AI capabilities to an existing .NET infrastructure, Semantic Kernel and Agent Framework make that possible without ever touching Python.

In short: Python offers speed and flexibility, .NET offers safety and scalability. The right question isn’t “which one is better?” — it’s “which one fits my situation?

Thanks for reading :)