Loading ToolBench
MCP server for exploring .NET assemblies, namespaces, types, and NuGet packages with support for filtering and pagination
The server defines 5 tools with reasonable structure but has significant gaps in description quality and schema completeness. Tool names are action-oriented (verb_noun pattern with '-Explorer' and 'Search'/'Versions' suffixes), but descriptions are incomplete and lack LLM-optimized guidance. All tools have JSON Schema input definitions with types, but parameter descriptions vary in quality. Output schemas are partially documented through model classes but not formally declared in tool definitions. Error handling is minimal, no recovery guidance or error classification visible in the code sample. The server is STDIO-only, which is a hard cap at 50 for protocol readiness. Overall, the server provides basic functionality but lacks production-grade polish in definition quality and error handling.
Retrieves types from specified namespaces supporting filters and pagination.
Retrieves namespaces from specified assemblies supporting filters and pagination (doesn't extract data from referenced projects. Notice that the project must be built before scanning.
Searches for NuGet packages on nuget.org with support for filtering and pagination.
Retrieves version history and dependency information for a specific NuGet package.
Retrieves referenced assemblies based on filters and pagination (doesn't extract data from referenced projects. Notice that the project must be built before scanning.
Tool descriptions lack LLM-optimized guidance and context. ReferencedAssembliesExplorer, NamespacesExplorer, and NamespaceTypes descriptions are incomplete (30-40 chars) and fail to explain WHEN to use each tool or how they differ. Descriptions should be 50-200 chars and answer: what does it do? when use it instead of similar tools? what does it return?
Output schemas are NOT formally documented in tool definitions. Tools return model objects (AssemblyToolResponse, NamespaceToolResponse, TypeToolResponse, etc.), but these structures are not declared as part of the tool definition, only inferred from service code. LLMs cannot see what fields to expect from each tool response.
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 | 40 | - | v1 |
Parameter descriptions are generic and lack constraint clarity. Example: 'fullTextFiltersWithWildCardSupport' description does not explain what 'wildcard' means operationally (is it * for any chars? ** for recursive?), what escape syntax is needed, or how multiple filters are combined (AND vs OR). Descriptions should be format/range/constraint-explicit.
No error handling or recovery guidance visible. If a projectFileAbsolutePath is invalid, a .csproj doesn't exist, or assembly scanning fails, the agent receives no actionable error message. No documentation of which errors are retryable vs user-fixable.
Tool compositions and dependencies not documented. ReferencedAssembliesExplorer must be called before NamespacesExplorer (to discover assembly names), but descriptions don't guide this sequencing. Agents cannot infer the multi-tool workflow.
No pagination total count returned. Response models include CurrentPage and AvailablePages but no TotalCount. LLMs cannot calculate result bounds or know if they've seen all items.