Loading ToolBench
MCP server for .NET template management, project analysis, and NuGet package operations
This is a specialized .NET template management server with generally well-structured tool definitions. Most tools have clear descriptions and documented parameter schemas. However, there are several issues that prevent a higher score: (1) Parameter descriptions sometimes lack detail about format/constraints, (2) Output schemas are not explicitly documented in the definitions provided, (3) Error handling guidance is present but not comprehensive across all tools, (4) Some tools have complex JSON input parameters that could be better decomposed. The server shows solid effort in documentation but falls short of production-grade polish.
Stop hand-editing stale NuGet versions. Scan a .csproj, .sln/.slnx, or directory for outdated PackageReference/PackageVersion entries and report (or apply) upgrades to the latest stable versions. Uses the feeds configured in the repository's NuGet.config. CPM-aware: updates Directory.Packages.props when present. Reports only by default; pass apply=true to write changes.
Analyze a solution or workspace directory. Returns project structure, target frameworks, CPM status, and NuGet configuration — essential context for template creation decisions.
Compare 2 or more templates side by side — parameters, auth support, AOT, framework options, and classifications. Use when deciding between templates (e.g., webapi vs webapp, blazorserver vs blazorwasm).
Execute a sequence of template operations (project + item templates) in order. For example, create a MAUI app then add specific pages/views. Each step can reference a different template. If a template is not installed, it will be auto-resolved from NuGet.
Analyze an existing .csproj project file and generate a reusable dotnet template that preserves its exact conventions: SDK type (e.g., MSTest.Sdk), package references with metadata (PrivateAssets, IncludeAssets), properties (OutputType, TreatWarningsAsErrors), Central Package Management, shared compiles, and content items. Solves the problem of 'dotnet new' creating generic projects that don't match repo conventions.
template_compose uses a single 'stepsJson' string parameter containing a JSON array instead of accepting structured array input. This forces LLMs to construct JSON strings, which is error-prone and violates the pattern of accepting natural structured input. Should decompose into step_1_template, step_2_template, etc. or accept a proper array schema.
template_dry_run and template_instantiate both accept 'parametersJson' as a string. LLMs struggle to construct valid JSON in string form. These should accept structured parameter objects or at minimum provide enum constraints and format examples in descriptions.
Output schemas are not documented in tool definitions. The source code shows responses are JSON-serialized (e.g., CreateFromExistingTool returns a structured response with status, templatePath, analysis, etc.), but LLMs cannot see what fields to expect. Tool descriptions should document the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 15 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
See exactly what files a template would create before committing. Supports auto-resolve from NuGet, parameter validation, and constraint checking.
Skip the CLI flags — describe what you want in plain English and get the right template with pre-filled parameters. No LLM required — uses keyword matching. Example: 'web API with authentication and controllers' → webapi + auth=Individual + UseControllers=true.
Get all details about a template in one call — parameters (names, types, defaults, choices), constraints, post-actions, supported hosts, and classifications. Can also inspect templates on NuGet that are not yet installed.
Install a template package from NuGet or a local folder/nupkg path. Idempotent: skips if already installed at the same version, offers upgrade if older. Returns install status AND full metadata for all templates in the package.
Get a structured listing of all installed templates as a resource. Returns identity, short names, name, description, author, classifications, language, and type for each template.
Parameter descriptions lack constraint documentation. For example, 'projectPath' is described as 'Full path to the .csproj file' but does not specify: required format, validation rules, whether relative paths are accepted, error handling if file doesn't exist. LLMs cannot infer these constraints.
template_from_intent uses keyword matching without documented matching rules or quality metrics. The description says 'No LLM required' but does not explain how matching works, what score threshold is applied, or how results are ranked. LLMs cannot predict which intents will match reliably.
Error handling responses (seen in CreateFromExistingTool) return JSON with 'error' field, but descriptions do not document error conditions, recovery guidance, or whether errors are retryable. LLMs have no guidance on next steps when a tool fails.