I
IvanMurzak/MCP-Plugin-dotnet
Expose a .NET app's methods as MCP tools
View on GitHub ↗Link checked 2026-11-12 · HTTP 200 · opens the vendor's own site
We have neither an install command nor a public remote endpoint from this repository, so we do not print a config. A made-up one is worse than none. How each client wires MCP up →
- Source
- collected from the abordage/awesome-mcp list · type: MCP server
- Harvest history
- first seen 2026-11-05 · last seen 2026-11-14 · seen 10× · listed by 10 sources
- Score
- score 1,003 · 10 sources · mcp
FAQ (answers come from our records)
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
first catalogued 2026-11-05;last seen 2026-11-14。There is no official certification or quality rating here — we record sources and dates only.
# MCP Plugin for .NET
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
## Overview
MCP Plugin for .NET is a comprehensive solution for integrating .NET applications with the Model Context Protocol (MCP). It allows you to easily expose methods and data from your .NET applications as Tools, Prompts, and Resources to AI assistants (like Claude) and other MCP clients.
### The Problem: Independent Lifecycles
Standard MCP servers are typically designed to be launched as subprocesses by the client (e.g., Claude Desktop spawns a Python script). This works well for lightweight scripts but creates challenges for complex .NET applications like Unity Engine, WPF Desktop Apps, or Game Servers:
1. Heavy Startup: These applications are often too heavy to be spawned repeatedly by an MCP client.
2. Independent Lifecycle: They often need to run independently (e.g., you are already working in the Unity Editor).
3. Live Context: You want to interact with the currently running instance (e.g., "Add a cube to the current scene"), not start a new, empty instance.
### The Solution: The Bridge Pattern
This project solves this by decoupling the MCP Server from your application using a Bridge Architecture:
1. McpPlugin (In-App): A lightweight library you add to your .NET application (e.g., Unity, WPF, Console). It connects to the bridge via SignalR.
2. McpPlugin.Server (Bridge): A high-performance gateway that the MCP Client (Claude) launches. It acts as a persistent mediator.
Why SignalR?
Resilience: Built-in automatic reconnection logic. If the bridge restarts, your app reconnects instantly.
Simplicity: Operates over a single HTTP port (default 8080). No complex firewall rules.
Bidirectional: The bridge can invoke tools in your app, and your app can push updates (logs, progress) back to the bridge.
## Architecture
The system uses a hub-and-spoke architecture where McpPlugin.Server acts as the central gateway.
mermaid
graph LR
subgraph "Your .NET Apps (SignalR Clients)"
A[Unity Editor] -- SignalR --> S
B[WPF Desktop] -- SignalR --> S
E[Game Server] -- SignalR --> S
end
subgraph "MCP Infrastructure (Bridge)"
S[McpPlugin.Server]
end
subgraph "AI / MCP Clients"
C[Claude Desktop] -- StdIO/HTTP --> S
D[MCP Inspector] -- StdIO/HTTP --> S
end
## Features
Attribute-Based Registration: Easily expose tools, prompts, and resources using [AiTool], [AiPrompt], and [AiResource] attributes. (The legacy [McpPluginTool], [McpPluginPrompt], [McpPluginResource] names remain available as [Obsolete] aliases for backward compatibility.)
Powered by ReflectorNet:
Complex Type Support: Seamlessly handle nested objects, collections, and custom types in tool parameters.
Fuzzy Matching: AI can find and call methods even with partial names or slightly mismatched signatures.
Automatic Schema Generation: Precise JSON schemas are generated for your C# types to help LLMs understand your code perfectly.
Real-time Bidirectional Communication: Uses SignalR for a persistent, low-latency link between your apps and the bridge.
Flexible Transport: The bridge supports both stdio (for local AI agents like Claude Desktop) and streamableHttp (for remote connections).
Dependency Injection: First-class support for Microsoft.Extensions.DependencyInjection.
MCP Plugin for .NET is a comprehensive solution for integrating .NET applications with the Model Context Protocol (MCP). It allows you to easily expose methods and data from your .NET applications as Tools, Prompts, and Resources to AI assistants (like Claude) and other MCP clients.
### The Problem: Independent Lifecycles
Standard MCP servers are typically designed to be launched as subprocesses by the client (e.g., Claude Desktop spawns a Python script). This works well for lightweight scripts but creates challenges for complex .NET applications like Unity Engine, WPF Desktop Apps, or Game Servers:
1. Heavy Startup: These applications are often too heavy to be spawned repeatedly by an MCP client.
2. Independent Lifecycle: They often need to run independently (e.g., you are already working in the Unity Editor).
3. Live Context: You want to interact with the currently running instance (e.g., "Add a cube to the current scene"), not start a new, empty instance.
### The Solution: The Bridge Pattern
This project solves this by decoupling the MCP Server from your application using a Bridge Architecture:
1. McpPlugin (In-App): A lightweight library you add to your .NET application (e.g., Unity, WPF, Console). It connects to the bridge via SignalR.
2. McpPlugin.Server (Bridge): A high-performance gateway that the MCP Client (Claude) launches. It acts as a persistent mediator.
Why SignalR?
Resilience: Built-in automatic reconnection logic. If the bridge restarts, your app reconnects instantly.
Simplicity: Operates over a single HTTP port (default 8080). No complex firewall rules.
Bidirectional: The bridge can invoke tools in your app, and your app can push updates (logs, progress) back to the bridge.
## Architecture
The system uses a hub-and-spoke architecture where McpPlugin.Server acts as the central gateway.
mermaid
graph LR
subgraph "Your .NET Apps (SignalR Clients)"
A[Unity Editor] -- SignalR --> S
B[WPF Desktop] -- SignalR --> S
E[Game Server] -- SignalR --> S
end
subgraph "MCP Infrastructure (Bridge)"
S[McpPlugin.Server]
end
subgraph "AI / MCP Clients"
C[Claude Desktop] -- StdIO/HTTP --> S
D[MCP Inspector] -- StdIO/HTTP --> S
end
## Features
Attribute-Based Registration: Easily expose tools, prompts, and resources using [AiTool], [AiPrompt], and [AiResource] attributes. (The legacy [McpPluginTool], [McpPluginPrompt], [McpPluginResource] names remain available as [Obsolete] aliases for backward compatibility.)
Powered by ReflectorNet:
Complex Type Support: Seamlessly handle nested objects, collections, and custom types in tool parameters.
Fuzzy Matching: AI can find and call methods even with partial names or slightly mismatched signatures.
Automatic Schema Generation: Precise JSON schemas are generated for your C# types to help LLMs understand your code perfectly.
Real-time Bidirectional Communication: Uses SignalR for a persistent, low-latency link between your apps and the bridge.
Flexible Transport: The bridge supports both stdio (for local AI agents like Claude Desktop) and streamableHttp (for remote connections).
Dependency Injection: First-class support for Microsoft.Extensions.DependencyInjection.
Listed badge (optional)
Copy this line into the README if you want the listing mark. Optional, and it does not affect being listed.
[](https://anclum.com/en/s/ivanmurzak-mcp-plugin-dotnet/)
- Source
- awesome · https://github.com/IvanMurzak/MCP-Plugin-dotnet
- Browse by field
- MCP servers
- Listed by
- 10 independent sources
- added
- today
More like this
Filed under
Every tag opens the full list for that filter. Counts are the live catalogue figures.