Dotnet Semantic MCP

语义的。网络MCP

基于Roslyn的AST代码智能，通过MCP提供服务。

你的AI代理阅读C#就像初级开发人员阅读小说一样：从左到右，从上到下，希望上下文最终到达。语义的。NET MCP修复了这个问题。它加载你的。NET解决方案导入Roslyn的语义编译器，构建完整的符号索引，并通过 模型上下文协议七个工具。四种资源。一个礼貌地告诉你的代理人停止使用的提示 read_file.

结果：您的代理将获得类型解析、调用图、继承链和跨项目引用。不是grep。字符串不匹配。对代码的实际编译器级理解。

建在。网10/C#14。输出默认为 卡通 （令牌优化对象表示法），这会减少JSON在大括号、引号和逗号上浪费的约60%的令牌。因为当你按令牌付费时，语法噪音是一种负担。

罗斯林优势（这不公平，我们不道歉）

让我们准确地说一下大多数代理项目掩盖的东西。

大多数语言工具都会生成AST:抽象语法树。结构解析。节点和令牌。带圆括号的表达式和标识符列表。当然，当你需要了解一个城市时，电话簿是有用的。AST告诉你 *写了什么*它不会告诉你它是什么 *手段*.

Roslyn并没有止步于语法。罗斯林制作了一个完整的 语义模型一 Compilation 对象，包含每个解析的类型绑定、每个重载解析、每个泛型类型参数推理、每个隐式转换、每个符号在每个项目边界上的可访问性。当你问罗斯林“做什么 var x = GetOrder() 决心？“，它不猜测。它告诉你 x 是 Task 因为 GetOrder() 回报 Task 因为三个项目之外的接口契约就是这么说的。它遍历了整个依赖关系图。它解决了 ` 链。它知道是哪一个 Dispose() 你是说当六种类型实现时 IDisposable`.

这不是AST。这是一个 编译器即服务。没有其他主流语言生态系统有如此可访问、如此快速、如此正确的替代品。

Python有 ast.parse()。它为您提供了一个语法树。没有类型信息。无跨模块分辨率。无过载歧义。你想要类型？单独运行mypy，解析其输出，祈祷版本匹配。

TypeScript具有TS编译器API。信用到期：它是最接近的竞争对手。但它为每个项目从头开始重新实现模块解析，限制了单仓库边界 ts.Program 对象是可变的，对并发访问不安全。祝你好运，在不破坏状态的情况下处理并发查询。

Java有Eclipse JDT和javac树。两者都需要一个正在运行的JVM，都没有公开干净的JVM Compilation 快照和增量重新编译是一个研究项目，而不是一个发布功能。

锈有 rust-analyzer卓越的工程设计，真正令人印象深刻的增量计算。但是 rust-analyzer 是IDE服务器，而不是库。你不嵌入它；你通过LSP与它交谈。LSP是为编辑而不是代理人设计的。该协议没有“在单个结构化响应中为我提供整个工作区中此函数的所有调用者”的概念

Roslyn从一开始就被设计成一个可嵌入的编译器平台。用于并发的不可变快照。每个文件的延迟语义模型计算。增量修复。完全跨项目符号解析。所有这些都可以作为NuGet包提供 dotnet add 并从您自己的流程中调用。

语义的。NET MCP通过MCP将整个语义模型暴露给编码代理。 不是一个附加了一些启发式类型猜测的语法树。实际编译器对代码的理解。每种已解决的类型。每一个束缚。每个跨项目参考。每个通用实例化。

这就是为什么C#和。NET是代理开发的最佳选择。不是因为语法偏好或运行时基准。因为编译器本身是一个可查询、可嵌入、并发安全的语义数据库。没有其他生态系统会免费提供给你这个。优点是结构化的，它与代码库大小相结合：解决方案越大、越复杂，“代理读取文本文件”和“代理查询语义模型”之间的差距就越大

问题，坦率地说

AI编码代理将源代码作为平面文本进行消费。他们看到了人物。Roslyn看到了符号、范围、绑定和关系。这两种观点之间的差距是bug、幻觉和浪费的上下文窗口存在的地方。

考虑当代理需要理解时会发生什么 OrderService.CreateOrder:

这不是一个舍入误差。这意味着代币成本降低了20倍，信息量也大大增加。建筑是一种权衡。这个不需要你付出任何代价。

论“振动编码”（一种简明、必要的不愉快）

有一种流行的运动，人们键入提示，接受LLM发出的任何代码，然后在不阅读的情况下发货。他们称之为“氛围编码”。他们自豪地发布了这篇文章。他们有播客。

让我直截了当地说：vibe编码不是工程。它甚至不是编程。它将你的判断外包给统计模型，然后假装对结果有信心。这相当于用一种你不读的语言签署合同，因为感觉很好。

感受代码船的人 O(n³) 他们无法解释的循环。它们引入了无法识别的安全漏洞。他们创造了无法偿还的技术债务，因为他们不了解资产。当他们的vibe编码应用程序在凌晨3点中断时，他们会打开一个新的聊天会话，并在中断的基础上进行vibe编码修复。海龟一路下来。

语义的。NET MCP的存在是出于相反的原因。它的存在是因为代理应该理解代码 *更好* 比文本扫描允许的还要糟糕。整个架构都是围绕给代理提供高级工程师多年来在代码库中构建的相同语义理解而构建的：类型关系、调用图、继承链、可访问性边界、解析泛型。当代理有这种理解时，它会编写更好的代码。它抓住了自己的错误。它知道在做出改变之前，下游会发生什么。

Vibe程序员希望代理能够快速行动。我们希望代理人离开 *正确的*不理解的速度只会产生大规模的错误。

如果你正在使用Semantic进行构建。NET MCP，您正在为使用编译器级语义上下文对代码进行推理的代理构建。您正在为审查、测试和了解船舶的工程团队进行建设。你正在为那些认为“它在我的机器上工作”是对话的开始而不是结束的人而构建。

如果您正在寻找工具来帮助您在不阅读LLM输出的情况下更快地接受它，那么您使用的是错误的存储库。我们祝你好运。你会需要它的。

需求

• .NET 10 SDK 或以后
• A.NET解决方案(.sln 或 .slnx)在工作目录中（自动发现）或明确指定
• 一台有足够RAM的机器，Roslyn可以完成它的工作（对于超过500个文件的解决方案，建议使用16GB）

入门指南

安装

选项1：作为全局工具安装（推荐）

# Clone, build, pack and install
git clone https://github.com/dotnet-semantic-mcp/dotnet-semantic-mcp.git
cd dotnet-semantic-mcp
dotnet build -c Release
dotnet pack src/DotnetSemanticMcp -c Release -o ./nupkg
dotnet tool install --global --add-source ./nupkg DotnetSemanticMcp

# Verify installation
dotnet-semantic-mcp --version

选项2：通过dotnetrun运行

dotnet build
dotnet test    # 265 tests. All passing.

CLI使用情况

# From any directory containing a .NET solution
cd /path/to/your/solution

# Global tool (after installation)
dotnet-semantic-mcp status
dotnet-semantic-mcp search "CreateOrder"
dotnet-semantic-mcp map --map-type solution
dotnet-semantic-mcp details --target OrderService.CreateOrder

# Or via dotnet run
dotnet run --project /path/to/dotnet-semantic-mcp/src/DotnetSemanticMcp -- search "CreateOrder"

看 完整CLI参考 对于所有命令。

MCP服务器模式

在您的AI客户端中进行配置(完整设置指南):

使用全局工具：

{
  "mcpServers": {
    "ast": {
      "command": "dotnet-semantic-mcp",
      "cwd": "/path/to/your/repo"
    }
  }
}

使用.NET运行：

{
  "mcpServers": {
    "ast": {
      "command": "dotnet",
      "args": ["run", "--no-build", "--project", "/path/to/dotnet-semantic-mcp/src/DotnetSemanticMcp"],
      "cwd": "/path/to/your/repo"
    }
  }
}

cwd 设置工作目录——服务器递归发现 .sln/.slnx 文件从那里。VS代码扩展可以使用 "cwd": "${workspaceFolder}".

自动发现解决方案文件 递归地 从工作目录（跳过 bin, obj, node_modules, .git等等）。全部 .sln/.slnx 找到的文件已加载--否 --solution 旗帜需要。要覆盖：传递 --solution path.sln 或设置 DotnetSemanticMcp:SolutionPath.

📖 看 入门指南 以获得完整的演练。

MCP表面积

工具（v1.0--核心分析）

工具（v2.0-扩展分析）

资源（v1.0）

提示（v1.0）

📖 完整的工具合同、参数和示例： 工具和资源规范 📖 推荐工作流程： 工作流模式

建筑

两种操作模式，下面是同一台发动机：

Program.cs ─── mode detection
├── MCP Mode ──→ Tools/ + Resources/ + Prompts/
└── CLI Mode ──→ Cli/CliRunner.cs
                    ↓
               Query/QueryEngine.cs
                    ↓
               Workspace/WorkspaceManager.cs ──→ Roslyn MSBuildWorkspace
                    ↓
               Projection/ ──→ TOON (default) or JSON

罗瑟琳 Compilation 对象是不可变的。查询在同一快照上并发运行。文件更改生成新的 Compilation 并进行原子交换。没有锁。没有撕裂的阅读。

📖 全面深入了解架构： 建筑 📖 并发模型、快照策略、DI： 运行时行为规范

路线图

v1.0 ✅ 发布7个工具、4个资源、1个提示、265个测试。只读分析。CLI模式。全局.NET工具打包。基金会。

v2.0 ✅ 发布：四个新工具，全部为只读：

• ast_dependencies --项目依赖关系图、循环检测、NuGet版本分析
• ast_diff --与DiffPlex集成的语义代码比较（了解破坏性更改与外观更改）
• ast_diff_unified --以类似git的格式生成统一的diff输出
• ast_attributes --DI、API、序列化理解的查询装饰器/注释

v3.0--扩展分析 📋 计划的：仍然是只读的，外部源访问：

• ast_complexity --圈/认知复杂性度量，热点分析
• ast_sourcelink --通过SourceLink解析NuGet包的源代码
• ast_decompile --用于闭源依赖关系的IL反编译（ILSpy）

v4.0——代码修改 🔮: 小心地解除只读约束：

• Git集成优先（自动提交、撤消、分支）作为安全网
• ast_rename -解决方案范围重命名（Roslyn经过验证的API）
• ast_add_member --向类添加方法/属性
• 稍后： ast_overwrite_member, ast_delete_member （需要成熟的Git集成）

📖 v2/v3工具的详细规格： v2-v3工具规范

文档

指南

规格

许可证

看 许可证.