If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/modelcontextprotocol/csharp-sdk shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 9 active contributors
• Distributed ownership (top contributor 34% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live modelcontextprotocol/csharp-sdk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/modelcontextprotocol/csharp-sdk.

What it runs against: a local clone of modelcontextprotocol/csharp-sdk — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in modelcontextprotocol/csharp-sdk | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of modelcontextprotocol/csharp-sdk. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/modelcontextprotocol/csharp-sdk.git
#   cd csharp-sdk
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of modelcontextprotocol/csharp-sdk and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "modelcontextprotocol/csharp-sdk(\\.git)?\\b" \\
  && ok "origin remote is modelcontextprotocol/csharp-sdk" \\
  || miss "origin remote is not modelcontextprotocol/csharp-sdk (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "ModelContextProtocol.slnx" \\
  && ok "ModelContextProtocol.slnx" \\
  || miss "missing critical file: ModelContextProtocol.slnx"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f ".github/workflows/ci-build-test.yml" \\
  && ok ".github/workflows/ci-build-test.yml" \\
  || miss "missing critical file: .github/workflows/ci-build-test.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/modelcontextprotocol/csharp-sdk"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The official C# SDK for the Model Context Protocol (MCP), enabling .NET applications to build and integrate with MCP clients and servers that standardize how applications provide context to Large Language Models. It provides three layered NuGet packages (Core, main, and AspNetCore) for low-level protocol interaction, dependency injection hosting, and HTTP-based MCP servers respectively. Multi-package monorepo structure: core protocol implementation likely in src/ModelContextProtocol.Core/, hosting/DI extensions in src/ModelContextProtocol/, and ASP.NET integration in src/ModelContextProtocol.AspNetCore/. Documentation lives in docs/ organized by concept (cancellation, capabilities, completions). Samples directory provides runnable reference implementations. Build driven by Directory.Build.props and Directory.Packages.props for centralized configuration.

.NET developers and architects building LLM-integrated applications who need to implement MCP clients or servers without managing protocol complexity. Teams using ASP.NET Core who want to expose MCP capabilities over HTTP, and library authors who need lightweight MCP support without heavy dependencies.

Production-ready and actively maintained. The project is officially maintained in collaboration with Microsoft, has a published NuGet package (ModelContextProtocol on nuget.org), comprehensive CI/CD workflows (.github/workflows/ includes build, test, code-coverage, and release automation), and organized release management skills (.github/skills/ documents version bumping and breaking-change tracking). Clear evidence of active stewardship with versioned packages and semantic versioning practices.

Standard open source risks apply.

Active maintenance with release automation: release.yml workflow, version-bump skills, and API compatibility checking (apicompat-apidiff.md) indicate regular versioning cycles. Copilot integration setup (.github/copilot-instructions.md, copilot-setup-steps.yml) suggests recent tooling improvements. Conformance testing (@modelcontextprotocol/conformance 0.1.13 in package.json) indicates alignment with cross-SDK compatibility standards.

git clone https://github.com/modelcontextprotocol/csharp-sdk && cd csharp-sdk && dotnet restore && dotnet build ModelContextProtocol.slnx && dotnet test

Daily commands: dotnet build ModelContextProtocol.slnx for full solution, or dotnet build src/ModelContextProtocol.Core/ for Core package only. Makefile likely wraps common tasks; run make to see targets. For samples, navigate samples/ directory and dotnet run in specific sample folder.

• README.md — Entry point explaining the three-package structure (Core, main, Extensions) and linking to API documentation every developer must understand before contributing.
• ModelContextProtocol.slnx — Solution file defining all projects and their relationships; essential for understanding the codebase structure and build dependencies.
• Directory.Build.props — Central property configuration for all projects (versioning, target frameworks, shared settings); changes here affect the entire SDK.
• Directory.Packages.props — Centralized NuGet package version management across all projects; critical for dependency consistency and security updates.
• .github/workflows/ci-build-test.yml — CI/CD pipeline definition showing build, test, and coverage requirements that all PRs must pass.
• CONTRIBUTING.md — Contribution guidelines, coding standards, and process that all developers must follow when submitting changes.
• .github/copilot-instructions.md — AI assistant instructions and codebase conventions that guide automated analysis and code generation for the repo.

Add a New Tool to an MCP Server

1. Create a new tool class inheriting from the tool base or implementing the IServerTool interface in your server project (docs/concepts/elicitation/samples/server/Tools/InteractiveTools.cs)
2. Implement tool metadata (name, description, input schema) in the Initialize method to register with MCP (docs/concepts/elicitation/samples/server/Tools/InteractiveTools.cs)
3. Register the tool in the server's Program.cs using dependency injection or direct AddTool/RegisterTool calls (docs/concepts/elicitation/samples/server/Program.cs)
4. Write unit tests following the pattern in the test project to validate tool invocation and error handling (docs/concepts/getting-started.md)

Add a New SDK Feature (Client or Server API)

1. Define the new API in the appropriate Core project interface or abstract class (ModelContextProtocol.slnx)
2. Update Directory.Build.props if the feature requires new dependencies or version bumps (Directory.Build.props)
3. Add corresponding documentation in docs/concepts/ with a concept guide and working sample (docs/concepts/getting-started.md)
4. Add conformance test coverage by updating the conformance test suite reference in package.json (package.json)
5. Submit PR with CONTRIBUTING.md checklist items (tests, docs, breaking-change assessment via .github/skills/breaking-changes/) (CONTRIBUTING.md)

Release a New SDK Version

1. Run the prepare-release Copilot skill to generate breaking-change classification and version bump recommendations (.github/skills/prepare-release/SKILL.md)
2. Update version numbers in Directory.Build.props and create release notes in CHANGELOG (if present) (Directory.Build.props)
3. Run CI pipeline (ci-build-test.yml) to ensure all tests pass on the release branch (.github/workflows/ci-build-test.yml)
4. Trigger release.yml workflow which publishes Core, main, and Extensions packages to NuGet (.github/workflows/release.yml)
5. Update README.md NuGet badge links and publish release notes to GitHub Releases (README.md)

Add a Concept Guide with Sample Code

1. Create a new markdown file in docs/concepts/{feature}/ explaining the feature and its use cases (docs/concepts/logging/logging.md)
2. Create a sample client project in docs/concepts/{feature}/samples/client/ with Program.cs demonstrating client-side usage (docs/concepts/logging/samples/client/Program.cs)
3. Create a sample server project in docs/concepts/{feature}/samples/server/ with Tools/*.cs showing server implementation (docs/concepts/logging/samples/server/Tools/LoggingTools.cs)
4. Add launchSettings.json and appsettings.json for local development, plus .http files for testing (docs/concepts/httpcontext/samples/Properties/launchSettings.json)

• .NET / C# (multi-target: net6.0+, net8.0) — Modern .NET ecosystem integration; cross-platform (Windows, Linux, macOS) with good async/await support for MCP's websocket/stdio transports.
• NuGet package distribution (three packages: Core, main, Extensions) — Standard .NET distribution mechanism; Core provides minimal dependencies for low-level usage, main adds hosting/DI, Extensions offers higher-level abstractions.
• MSBuild + Directory.Build.props/Directory.Packages.props — Enterprise-grade centralized build configuration; enforces consistent versioning, frameworks, and code analysis rules across all projects.
• GitHub Actions (ci-build-test.yml, codeql.yml, release.yml) — Native GitHub integration; automates testing, security scanning, and multi-package release orchestration on every commit and tag.
• Copilot Skills (.github/skills/) for breaking-change detection and version bumping — Automated semantic versioning and API compatibility analysis; reduces manual release overhead and human error.

• Three separate NuGet packages (Core, main, Extensions) instead of a single monolithic package

  • Why: Allows consumers to choose minimal dependencies (Core) or convenience features (main/Extensions) based on use case.
  • Consequence: Higher maintenance burden: must coordinate versioning, manage compatibility across packages, and test integration between them.

• Centralized version management in Directory.Build.props instead of per-project versioning

  • Why: Ensures all three packages release with synchronized versions, preventing accidental version skew.
  • Consequence: Any SDK change (even in Extensions) bumps all package versions, which may inflate version numbers for rarely-changed packages.

• Copilot Skills for release automation (breaking-change classification, version bumping) rather than purely automated semantic versioning

  • Why: Allows human judgment on whether a change is truly breaking or a minor enhancement; more flexible than strict semver rules.
  • Consequence: Release process is semi-automated and requires human review; potential for inconsistency if Copilot instructions drift.

• Samples stored in docs/concepts/ (not separate example repo) with full .csproj files

  • Why: Concept samples stay close to documentation and are easy to build/test alongside docs; reduces outdated example risk.
  • Consequence: Documentation

Package layering requires understanding dependency graph: Core has no hosting, main depends on Core and adds DI, AspNetCore depends on main for HTTP exposure — breaking this ordering causes runtime failures. Strong naming via Open.snk suggests assembly signing is required; check Directory.Build.props for SignAssembly setting. Conformance tests via npm (@modelcontextprotocol/conformance) require Node.js installed alongside .NET for CI validation. Multi-targeting likely configured in Directory.Build.props; local .NET SDK version must support target frameworks or restore fails silently.

• Model Context Protocol (MCP) — The entire SDK is a concrete implementation of MCP; understanding the protocol spec is essential to meaningful contributions
• Dependency Injection (Microsoft.Extensions.DependencyInjection) — Core hosting pattern in src/ModelContextProtocol/ layer; configuring services, lifetimes, and factories requires DI knowledge
• Request-Response Message Passing — MCP protocol is fundamentally async request-response; understanding how messages flow through handlers in Core is critical
• Cancellation Tokens (CancellationToken) — Documented as a core concept (docs/concepts/cancellation/); used throughout async APIs for graceful shutdown and timeout handling
• Capability Negotiation — MCP clients and servers advertise capabilities; the SDK must serialize/deserialize capability sets correctly (docs/concepts/capabilities/)
• Multi-Targeting (.NET Framework, .NET Core, .NET Standard) — Directory.Build.props likely defines multiple target frameworks; understanding csproj syntax and platform-specific APIs is required for compatibility
• Strong-Named Assemblies (Code Signing via Open.snk) — SDK uses Open.snk for assembly signing; affects versioning, GAC installation, and security policies in enterprise .NET environments

• modelcontextprotocol/python-sdk — Parallel official MCP SDK for Python; cross-reference protocol implementation details and test patterns
• modelcontextprotocol/typescript-sdk — Parallel official MCP SDK for TypeScript/Node.js; valuable for understanding protocol semantics independent of language
• modelcontextprotocol/servers — Reference MCP server implementations in multiple languages; test compatibility and understand typical tool/resource patterns
• modelcontextprotocol/specification — Official MCP protocol specification; normative source for request/response shapes and capability definitions
• microsoft/semantic-kernel — Complementary Microsoft library for LLM integration in .NET; shows downstream usage patterns for this SDK in agent frameworks

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for cancellation token handling in ModelContextProtocol.Core

The repo has a docs/concepts/cancellation/cancellation.md concept guide, indicating cancellation is a core feature. However, there's no visible test suite for cancellation scenarios in the file structure. This is critical for a protocol SDK where proper cancellation prevents resource leaks and hanging connections. New contributors can add tests covering: token propagation across client/server boundaries, timeout scenarios, and graceful shutdown sequences.

• [ ] Create src/ModelContextProtocol.Core.Tests/CancellationTests.cs
• [ ] Add test cases for CancellationToken propagation in client/server communication
• [ ] Add test cases for timeout handling and token expiration
• [ ] Add test cases for cancellation during tool invocation and resource streaming
• [ ] Reference docs/concepts/cancellation/cancellation.md in test documentation
• [ ] Verify tests pass in ci-build-test.yml workflow

Add HTTP context and ASP.NET Core integration tests for docs/concepts/httpcontext/httpcontext.md

The file structure shows docs/concepts/httpcontext/ exists with httpcontext.md and samples/, but there appear to be no dedicated test files for HTTP context scenarios. HTTP integration is critical for .NET applications. A new contributor should add tests validating HttpContext extraction, request/response handling, and middleware integration patterns referenced in the documentation.

• [ ] Create src/ModelContextProtocol.Tests/HttpContextIntegrationTests.cs
• [ ] Add tests for HttpContext propagation in MCP server scenarios
• [ ] Add tests for extracting headers, user identity, and connection info from HttpContext
• [ ] Add tests validating the samples in docs/concepts/httpcontext/samples work correctly
• [ ] Add tests for concurrent HTTP context handling in multi-request scenarios
• [ ] Ensure tests follow patterns from elicitation samples already in the repo

Add conformance test integration workflow referencing @modelcontextprotocol/conformance 0.1.13

The package.json shows @modelcontextprotocol/conformance 0.1.13 is already a dependency, but there's no visible GitHub Action running these conformance tests. This is a critical gap—conformance tests validate SDK compliance with the MCP spec across all language SDKs. A contributor should create a workflow that runs conformance tests against both sample client and server implementations.

• [ ] Create .github/workflows/conformance-tests.yml (referencing ci-build-test.yml pattern)
• [ ] Configure workflow to install npm dependencies and run conformance suite against ModelContextProtocol.Core
• [ ] Add test target for docs/concepts/elicitation/samples/server and docs/concepts/elicitation/samples/client
• [ ] Report conformance results as workflow artifacts
• [ ] Document conformance test status in README.md or docs/concepts/getting-started.md
• [ ] Validate integration with existing Dependabot configuration for @modelcontextprotocol/conformance updates

• Add missing XML documentation comments (///) to public APIs in src/ModelContextProtocol.Core/; scan for TODO-marked public types and generate stubs from existing patterns in adjacent files
• Expand docs/concepts/ with new concept pages (e.g., docs/concepts/error-handling/error-handling.md, docs/concepts/tool-discovery/) by studying README examples and creating markdown with code samples from samples/ directory
• Write integration tests for AspNetCore HTTP transport: create src/ModelContextProtocol.AspNetCore.Tests/HttpServerIntegrationTests.cs covering request routing, middleware ordering, and protocol compliance against reference server-everything

The C# SDK repository demonstrates a solid security posture with established security policies, proper vulnerability reporting guidelines via GitHub Security Advisory process, and CI/CD security controls (CodeQL analysis, dependabot configuration). However, there are opportunities for improvement including updating test dependencies, clarifying the purpose of the strong naming key file, and implementing CODEOWNERS for critical security-sensitive code paths. The overall security score reflects a mature, well-maintained open-source project with minor recommendations for enhancement.

• Medium · Outdated MCP Conformance Test Dependency — package.json - dependencies/@modelcontextprotocol/conformance. The @modelcontextprotocol/conformance package version 0.1.13 is pinned and may contain unpatched security vulnerabilities. The package.json indicates this is used for integration and conformance testing, which could affect test integrity and security validation. Fix: Regularly update to the latest version of @modelcontextprotocol/conformance. Implement automated dependency scanning and vulnerability alerts. Consider using Dependabot configuration (already present in .github/dependabot.yml) to track updates.
• Low · Potential Information Disclosure via GitHub Skills Configuration — .github/skills/*, .github/copilot-instructions.md. The .github/skills directory contains reference documentation for breaking-changes, version bumping, and release procedures. While not sensitive in nature, these files could potentially be leveraged to understand internal release processes. The repository also contains a copilot-instructions.md file that may expose operational details. Fix: Review the content of GitHub skills and copilot instructions to ensure no sensitive operational details are exposed. Consider restricting access to these files if they contain non-public procedures.
• Low · Missing CODEOWNERS File — Root directory (missing .github/CODEOWNERS). The repository does not appear to have a CODEOWNERS file visible in the provided file structure. This could lead to unauthorized code changes or security patches being merged without proper review from security-responsible maintainers. Fix: Create a .github/CODEOWNERS file that designates security-responsible maintainers for critical paths, particularly for cryptography, authentication, and data handling components.
• Low · Open.snk Key File Exposure Risk — Open.snk. The presence of 'Open.snk' (a strong naming key file) in the repository root is a potential security concern if this key is used for production assemblies. Strong naming keys should typically be kept secure and not committed to version control. Fix: Verify that Open.snk is an intentionally public key for the open-source project and not a private signing key. If it's intended to be public, document this clearly. Ensure private production keys are never committed to the repository. Consider using GitHub Secrets for any sensitive key management.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.