Loading ToolBench
An MCP server that exposes .NET CLI capabilities (SDK/Runtime inspection) via Model Context Protocol. Allows LLMs to query installed .NET SDKs, runtimes, and environment information.
This is a READ-ONLY .NET CLI wrapper with 6 tools. All tools have descriptions and are marked with [McpServerTool] attributes, indicating proper registration. However, input schemas are largely inferred from method signatures rather than explicitly declared in JSON Schema format, the codebase shows parameter annotations via [Description] attributes but no explicit JSON Schema definitions visible. Output schemas are not documented; tools return JSON strings without declared response structures. Error handling is present (try-catch blocks) but generic, errors serialize to {'error': ex.Message} without recovery guidance. Naming is clear and verb-based (list_, get_, check_). Descriptions are adequate (70-150 chars) but could be more actionable for LLM selection. This is a typical mid-tier community server, competent but missing production-grade schema rigor and error handling.
Checks if a specific .NET SDK version is installed on the system
Gets detailed .NET information including SDK version, runtime versions, and environment. Executes: dotnet --info
Gets the effective .NET SDK version being used in the specified directory. This respects global.json and roll-forward rules. Executes: dotnet --version (in the specified directory)
Gets the latest installed .NET SDK version
Lists all installed .NET runtimes with their versions and installation paths. Executes: dotnet --list-runtimes
Lists all installed .NET SDKs with their versions and installation paths. Executes: dotnet --list-sdks
No explicit JSON Schema definitions visible for tool inputs. Parameters are declared via C# [Description] attributes on method parameters, but no formal JSON Schema with 'type', 'properties', 'required' fields is shown.
Output schemas are undocumented. Tools return JsonSerializer.Serialize(result, ...) with anonymous objects (new { count = ..., sdks = ... }), but the response structure is not formally declared. LLMs cannot know in advance what fields to expect without reverse-engineering the code. LLMs need to know what fields to expect so they can plan downstream tool calls.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Generic error handling without recovery guidance. All tools catch exceptions and return {'error': ex.Message}. Check installation or run dotnet --list-sdks directly.' Currently, ex.Message gives only the .NET CLI error, not actionable next steps.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are READ_ONLY, but this is not declared via MCP tool annotations. Per current spec (2026-07-28), tools should include readOnlyHint: true to signal to clients that they are safe to call without side effects.
Parameter descriptions could be more LLM-actionable. For example, check_sdk_version's version parameter says 'The SDK version to check (e.g., '8.0.202' or '9.0.302')', the examples are good, but the description does not explicitly state the format (SemVer-like, 3 numeric parts separated by dots) or constraints.
No pagination or result limit guidance for list operations. list_installed_sdks and list_installed_runtimes return all results as a flat array.
Missing parameter descriptions for get_effective_sdk's workingDirectory. The parameter has a description via [Description] attribute, but it does not specify the format expected (absolute path? relative? home-dir-relative?) or defaults ('uses the current working directory' is stated, but unclear if null/empty triggers the default or if an explicit path is required).