Dotnet MCP Server

Dotnet MCP server exists for a simple reason — assistants are far more useful when they can act on Dotnet directly instead of describing what you should do. Search, inspect, preview, and create .NET projects from dotnet new templates via AI agents.

What you get

An MCP server that lets AI agents work with dotnet new templates — search, inspect, preview, and create projects through natural conversation instead of memorizing CLI flags.

What the assistant can call

Once Dotnet is connected, these are the calls the assistant has available:

• template_search — Search locally and on NuGet.org — one call, ranked results
• template_list — List what's installed, filter by language/type/classification
• template_inspect — Parameters, constraints, post-actions — all in one shot
• template_instantiate — Create a project. Not installed? Auto-resolves from NuGet. Elicits missing params interactively
• template_dry_run — Preview files without touching disk
• template_install — Install a package (idempotent — skips if already there)
• template_uninstall — Remove a template package
• templates_installed — Inventory of everything installed
• template_from_intent — "web API with auth" → webapi + auth=Individual — no LLM needed
• template_create_from_existing — Analyze a .csproj → generate a reusable template matching repo conventions
• template_compose — Execute a sequence of templates (project + items) in one workflow
• template_suggest_parameters — Suggest parameter values with rationale based on cross-parameter relationships

Setting it up

Being a remote server, there is no local install. You register the endpoint with your client, authorise it once, and the tools appear.

Configuration and credentials

You will need 2 environment variables: MCP_TEMPLATE_TOOL_PROFILE, MCP_TEMPLATE_HTTP_URL. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

Choosing this one

Plenty of AI and media services servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Dotnet's toolset — template_search, template_list, template_inspect and 11 more — is a fair guide to whether it matches your workflow. It is maintained by YuliiaKovalova; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Before you rely on it

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Dotnet.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the dotnet mcp server does with a few real requests.