Loading ToolBench
NestJS module for creating Model Context Protocol (MCP) servers
MCP-Nest provides a NestJS framework for building MCP servers with 16 tools across greeting, validation, and test scenarios. Most tools have descriptions (avg 65 chars) and Zod-based input schemas with parameter descriptions. However, naming lacks action verbs (greet-* vs get_greeting), several tools are test/demo-only with minimal real-world value, and output schemas are inconsistently documented. Error handling is present but generic. The framework itself is well-structured, but tool definitions show patterns of incomplete composition and unclear purpose.
A sample tool that gets a header from the request
Returns a personalized greeting in the user's preferred language
Returns a personalized greeting with interactive language selection
Returns a structured greeting message with language metadata
Returns a simple Hello, World! message
A sample tool that gets the user by name
A sample tool that gets the user by name
Tool names lack action verbs. 'greet-world', 'greet-user', 'hello-world' do not follow verb_noun convention (get_, create_, send_). LLMs infer intent from names, these names are ambiguous about whether they retrieve, generate, or modify state.
Multiple test/demo tools ('simple-tool', 'hello-world-error', 'not-mcp-greeting', 'invalid-output-schema-tool') exist only to validate framework behavior, not to provide real functionality. These pollute the tool namespace and confuse agents about actual capabilities.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
A sample tool that throws an error
A sample request-scoped tool that gets the user by name
A sample tool with annotations
Returns an object that does not match its outputSchema
Returns a plain object, not MCP-compliant
Returns a plain object with outputSchema
A tool to test outputSchema
A simple tool that gets the user by name
A tool to test input validation with required parameters
Output schemas are inconsistently documented. 'greet-user-structured' declares outputSchema in code, but most other tools return unstructured text or plain objects without schema documentation. LLMs cannot plan downstream operations without knowing return types.
Error handling is generic. 'hello-world-error' and error paths in 'greet-user-interactive' return plain text error messages without recovery guidance. Per pattern:recovery-guide, errors should tell LLMs what to do next (retry, ask user, or fail).
Parameter descriptions are minimal. 'simple-tool' has no input schema visible; 'get-request-scoped' has empty input {}. Several tools lack parameter-level descriptions beyond the Zod schema, forcing LLMs to infer meaning from names alone.