Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/net-mcp-server/issues.md or /mcp/net-mcp-server/issues.json, or Pod over MCP.

Reported issues for .NET MCP Server

Pod holds 23 of 161 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to .NET MCP Server.

Most discussed

Implement tool-surface consolidation (Phase 1: add consolidated tools alongside existing)

Track implementation of the consolidated 10-tool surface described in doc/tool-surface-consolidation.md.

Scope (Phase 1 / non-breaking):

Read the thread · 2026-01-08 · closed · 2 comments

Release install/package validation (v1.0)

Goal

Ensure a smooth, repeatable install/run experience for v1.0 across supported environments.

Scope

Read the thread · 2026-01-02 · closed · 2 comments

feat: estimate and report workflow-level token savings (MCP vs non-MCP baseline)

Summary

Track and report estimated end-user token savings for complete workflows by comparing:

This should measure more than per-tool micro-optimizations and provide a clear overall savings number per workflow.

Problem

Current token-efficiency issues (#446-#451) improve specific responses and APIs, bu

Read the thread · 2026-05-30 · closed · 1 comment

feat: add minimal { success, summary } structuredContent to mutating tool actions

Summary

Mutating actions -- dotnet_project { New, Clean, Restore, Pack, Format, Publish }, dotnet_package { Add, Remove, Update }, dotnet_solution { Create, Add, Remove } -- currently return only raw CLI text. AI clients must parse this text to determine success/failure, which is fragile and token-expensive.

Proposed Change

Add a minimal MutationResult to structuredContent for all mutating actions:

{
  "success": true,
  "summary": "Package 'Newtonsoft.Json' (13.0.3) 

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/449) · 2026-05-30 · closed · 1 comment

### Use package@version for template packs (avoid deprecated :: separator)

#### Summary
MCP emitted a template package identifier using `::` (e.g., `Aspire.ProjectTemplates::13.1.0`) and `dotnet new` warned that `::` is deprecated in favor of `@`.

#### Expected
Emit `@` for package version selection:
- `Aspire.ProjectTemplates@13.1.0`

#### Acceptance criteria
- Commands use `@` when a version is specified.
- No behavior change when no version is provided.

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/296) · 2026-01-13 · closed · 1 comment

### `dotnet_sdk InstallTemplatePack`: treat exit code 106 (already installed) as success-with-message

#### Summary
When installing a template pack that is already installed (e.g., `Aspire.ProjectTemplates`), the underlying CLI returns exit code **106** (“already installed”). MCP currently surfaces this as `success: false`, breaking idempotent automation.

#### Repro
1. Ensure a template pack is already installed.
2. Call `dotnet_sdk` (`InstallTemplatePack`) for the same package/version.

#### Actual
- `exitCode: 106`
- `success: false`

#### Expected
Treat exit code 106 as **success-with-message

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/294) · 2026-01-13 · closed · 1 comment

### Add Telemetry & Metrics Tool with Message Filters (dotnet_server_metrics)

Expose lightweight, privacy-respecting metrics and leverage MCP SDK 1.0's Message Filters for telemetry collection.

## Tool: dotnet_server_metrics
Returns counts per tool, avg duration ms, cache hit rate.

## Implementation

### Metrics Accumulator (original scope)
- In-memory metrics collection
- JSON response with per-tool stats
- Reset metrics subcommand
- No PII stored

### Message Filters Integration (new — requires MCP SDK 1.0)
MCP SDK 1.0 introduces **Message Filters** — middleware for i

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/63) · 2025-10-31 · closed · 1 comment

### Add Prompt Definitions, Discovery Optimization & Elicitation Support

Provide predefined prompts, enhance tool discovery, and leverage MCP SDK 1.0's Elicitation feature for interactive user input during tool execution.

## Scope

### Prompt Catalog & Discovery (original scope)
- Static prompt catalog (e.g., create_new_webapi, add_package_and_restore)
- Add tags metadata for semantic grouping
- Optional toolSearch endpoint returning ranked suggestions

### Elicitation Support (new — requires MCP SDK 1.0)
MCP SDK 1.0 introduces **Elicitation** — the ability for the 

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/62) · 2025-10-31 · closed · 1 comment

## Most recent

### Opportunity: OpenTelemetry trace-context propagation (SEP-414)

## Opportunity: OpenTelemetry trace-context propagation (SEP-414)

Part of #481.

SDK 2.0 propagates W3C Trace Context (`traceparent`/`tracestate`) across JSON-RPC messages built-in, using ActivitySource/Meter `"Experimental.ModelContextProtocol"`. This complements the existing telemetry stack (`DotNetMcp/Telemetry/*`).

### Tasks
- [ ] Verify incoming trace context is extracted and parented to server-side activities once on 2.0.
- [ ] Ensure the existing telemetry/metrics don't conflict

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/493) · 2026-06-30 · open · 0 comments

### Opportunity: first-class MCP Apps APIs (SEP-1865)

## Opportunity: first-class MCP Apps APIs (SEP-1865)

Part of #481.

The server already exposes `McpAppsResources` (`DotNetMcp/Resources/McpAppsResources.cs`). SDK 2.0 promotes MCP Apps to a structured extension with typed APIs: `McpApps.ExtensionId` (`io.modelcontextprotocol/ui`), `McpUiToolMeta`, and the `[McpAppUi]` attribute (diagnostic `MCPEXP003`, experimental).

### Tasks
- [ ] Evaluate moving `McpAppsResources` to the typed `ModelContextProtocol.Extensions.Apps` APIs.
- [ ] Use `

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/492) · 2026-06-30 · open · 0 comments

### Opportunity: JSON Schema 2020-12 output schemas (SEP-2106)

## Opportunity: JSON Schema 2020-12 output schemas (SEP-2106)

Part of #481.

SDK 2.0 allows any valid JSON Schema 2020-12 document for `Tool.OutputSchema` (not just `{"type":"object"}`), and fixes `$ref` resolution after output-schema wrapping. `Tool.InputSchema` is now required during deserialization.

### Tasks
- [ ] Review tools that return structured content; adopt richer, non-object output schemas where useful.
- [ ] Verify `$ref` usage resolves correctly post-wrapping.
- [ ] Conf

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/491) · 2026-06-30 · open · 0 comments

### Opportunity: TTL for list results (SEP-2549)

## Opportunity: TTL for list results (SEP-2549)

Part of #481.

SDK 2.0 adds optional `TimeToLive` (`TimeSpan?`) and `CacheScope` to `tools/list`, `prompts/list`, `resources/list`, and `server/discover` results via `ICacheableResult`. This pairs naturally with the existing caching infrastructure (`Caching/CachedResourceManager.cs`, `CacheMetrics.cs`) to reduce client round-trips.

### Tasks
- [ ] Evaluate emitting `TimeToLive`/`CacheScope` on list results, sourcing TTLs from the existing 

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/490) · 2026-06-30 · open · 0 comments

### Update documentation for SDK 2.0 / 2026-07-28 spec

## Update documentation for SDK 2.0 / 2026-07-28 spec

Part of #481.

### Tasks
- [ ] `doc/sdk-integration.md` — SDK 2.0 version, capability changes.
- [ ] `doc/machine-readable-contract.md` — `ServerFeatureSupport` changes (AsyncTasks, McpLogging, Sampling).
- [ ] `doc/capability-not-available.md` — error-code/capability updates from #SUB6.
- [ ] `doc/sdk-v1.1-compatibility.md` — note 2.0 migration and supersession.
- [ ] `README.md` — update any SDK version references and feature clai

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/489) · 2026-06-30 · open · 0 comments

### Fix tests for SDK 2.0

## Fix tests for SDK 2.0

Part of #481.

The test project (`DotNetMcp.Tests`) references `ModelContextProtocol` 1.4.0 and includes contract/conformance tests that may assert on changed surface.

### Tasks
- [ ] Bump the test project to SDK 2.0.x (tracked with #SUB2).
- [ ] Update/remove tests that reference removed experimental Tasks types (#SUB3).
- [ ] Ensure any `Tool` fixtures provide `InputSchema` (now required on deserialization — SEP-2106).
- [ ] Update error-code assertions aff

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/488) · 2026-06-30 · open · 0 comments

### Review error codes (-32002 deprecation, renumbered protocol codes)

## Review custom error codes (`-32002` deprecation, renumbered protocol codes)

Part of #481.

`DotNetMcp/Errors/McpErrorCodes.cs` defines custom codes, including `ResourceNotFound = -32002` and `CapabilityNotAvailable = -32001`.

SDK 2.0 / spec changes:
- **SEP-2164**: `-32002` resource-not-found is deprecated in favor of `-32602 InvalidParams` under `2026-07-28` (SDK auto-selects by negotiated version).
- Protocol error codes renumbered: `HeaderMismatch -32001 → -32020`, `MissingRequir

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/487) · 2026-06-30 · open · 0 comments

### Migrate Elicitation to MRTR and verify legacy back-compat

## Migrate Elicitation to Multi Round-Trip Requests (MRTR) and verify back-compat

Part of #481.

Elicitation is used for destructive-op confirmation:
- `DotNetCliTools.Project.Consolidated.cs` (`server.ElicitAsync(...)`)
- `DotNetCliTools.Solution.cs` (`server.ElicitAsync(...)`)

Under `2026-07-28`, server→client requests (elicitation/sampling/roots) are removed and replaced by declarative MRTR `inputRequests`/`inputResponses`. The SDK ships a back-compat resolver, so existing `ElicitAs

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/486) · 2026-06-30 · open · 0 comments

### Address Roots/Sampling/Logging deprecations (MCP9005)

## Address Roots / Sampling / Logging deprecations (`MCP9005`)

Part of #481.

SDK 2.0 marks Roots, Sampling, and Logging `[Obsolete]` under the shared diagnostic `MCP9005`. They remain functional on legacy protocol versions but are removed/relocated under `2026-07-28`.

Affected code:
- **Roots** — `WorkspaceDiscovery.cs` reads `ClientCapabilities.Roots` and calls `RequestRootsAsync`.
- **Sampling** — AI error interpretation gated on `ClientCapabilities.Sampling` in `DotNetCliTools.Proj

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/485) · 2026-06-30 · open · 0 comments

### Rewrite Tasks integration for SEP-2663 (remove IMcpTaskStore)

## Rewrite Tasks integration for SEP-2663 (highest-impact break)

Part of #481.

SDK 2.0 **removes** the experimental Tasks API and replaces it with the SEP-2663 Tasks **extension**. This server currently depends on the removed surface:
- `Program.cs`: `builder.Services.AddSingleton<IMcpTaskStore, InMemoryMcpTaskStore>();`
- `DotNetCliTools.Core.cs`: `private readonly IMcpTaskStore? _taskStore;` (constructor-injected)
- `DotNetCliTools.Misc.cs`: `AsyncTasks = _taskStore != null` in `Serve

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/484) · 2026-06-30 · open · 0 comments

### Bump ModelContextProtocol 1.4.0 -> 2.0.x in both projects

## Bump `ModelContextProtocol` 1.4.0 → 2.0.x

Part of #481. Blocked by the governance-package gating issue (#SUB1).

Update the package reference in both projects and resolve the resulting compile breaks (tracked in sibling issues).

### Tasks
- [ ] Update `ModelContextProtocol` to `2.0.x` in `DotNetMcp/DotNetMcp.csproj`.
- [ ] Update `ModelContextProtocol` to `2.0.x` in `DotNetMcp.Tests/DotNetMcp.Tests.csproj`.
- [ ] Restore/build and triage the compiler errors and `MCP9005`/`MCPEXP*` 

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/483) · 2026-06-30 · open · 0 comments

### Gating: confirm a 2.0-compatible AgentGovernance extension

## Gating dependency: 2.0-compatible AgentGovernance extension

Part of #481.

`Microsoft.AgentGovernance.Extensions.ModelContextProtocol` **4.0.0** is referenced in `DotNetMcp/DotNetMcp.csproj` and is pinned to the **1.x** MCP SDK. It is wired in via `WithGovernance(...)` in `Program.cs`.

This is the most likely **external blocker** for the SDK 2.0 upgrade: the version bump cannot land until a governance package built against SDK 2.0 is available (or governance is made optional/removed f

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/482) · 2026-06-30 · open · 0 comments

### Upgrade to MCP C# SDK 2.0 (2026-07-28 spec)

## Summary

Adopt the **MCP C# SDK 2.0** ([`modelcontextprotocol/csharp-sdk` v2.0.x](https://github.com/modelcontextprotocol/csharp-sdk/releases/tag/v2.0.0-preview.1)), aligned with the **2026-07-28 MCP specification**. This is a tracking issue for the upgrade from `ModelContextProtocol` **1.4.0** → **2.0.x**.

SDK 2.0 is **backward-compatible at the protocol level** (clients/servers auto-negotiate down to the legacy `initialize` handshake). API-surface breaks are limited to (1) capabiliti

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/481) · 2026-06-30 · open · 0 comments

### A/B testing: validate token savings heuristics against real LLM token counts

## Summary

The token savings estimation system (`TokenSavingsEstimator`, `TokenizerApproximation`, `ModelFamily`) currently uses **heuristic approximations** - chars-per-token ratios and baseline scale factors - to estimate token counts. These values are educated guesses based on published tokenizer research, but they have not been validated against real-world MCP interactions.

We should run structured A/B comparisons to capture actual token counts and validate (or tune) these heuristics.

## 

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/462) · 2026-06-01 · closed · 0 comments

### A/B testing: validate token savings heuristics against real LLM token counts

## Summary

The token savings estimation system (TokenSavingsEstimator, TokenizerApproximation, ModelFamily) currently uses **heuristic approximations** — chars-per-token ratios and baseline scale factors — to estimate token counts. These values are educated guesses based on published tokenizer research, but they have not been validated against real-world MCP interactions.

We should run structured A/B comparisons to capture actual token counts and validate (or tune) these heuristics.

## What n

[Read the thread](https://github.com/jongalloway/dotnet-mcp/issues/461) · 2026-06-01 · open · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/jongalloway/dotnet-mcp/issues).