Loading ToolBench
An MCP server that generates code based on the Domain-Driven Design methodology.
This MCP server demonstrates basic tool registration but has significant gaps in definition quality. Of the 6 tools, only 1 (generateEntity) has a visible, detailed input schema in the source code. The remaining 5 tools (generateValueObject, generateRepository, generateService, generatePostgreSQLRepository, generateDynamoDBRepository) have their definitions inferred from index.ts registration but lack visible schema details in the provided source excerpt. Two tools (generatePostgreSQLRepository, generateDynamoDBRepository) have detailed schemas visible in the metadata but the others do not. Descriptions are present but brief (10-50 chars for most tools), lacking the 50-200 char guidance window that LLMs require for tool selection. Parameter descriptions are minimal or missing for 4 of 6 tools. No error handling guidance is visible. Tool names follow verb_noun pattern (generate*), which is good, but the descriptions do not explain when to use each tool vs. similar ones (e.g., when to use generateRepository vs generatePostgreSQLRepository vs generateDynamoDBRepository). No output schemas are documented. The server lacks idempotency guarantees, error classification, and recovery guidance, all critical for an agent scaffolding system.
Generates a DynamoDB repository implementation using ElectroDB for an aggregate.
Generates a DDD entity, optionally as an aggregate root. Assistant alert: Write the code to the named output files, exactly as the generator produced it. The generator itself does not write the code to disk. Assistant alert: Disregard compilation errors in the generated code and leave them for the human to fix.
Generates a PostgreSQL repository implementation using Kysely for an aggregate.
Generates a DDD repository interface.
Generates a DDD service.
Generates a DDD value object.
Four of six tools (generateValueObject, generateRepository, generateService, and partially visible generatePostgreSQLRepository/generateDynamoDBRepository in index.ts) lack visible input schema definitions in the provided source code. Only generateEntity and the two database repositories have detailed schemas shown.
Tool descriptions are extremely brief (10-50 characters for most tools). generateValueObject, generateRepository, and generateService each have only 1-sentence descriptions that do not explain WHEN to use them instead of similar tools, what context they generate code for, or what output format to expect.
generateEntity description contains assistant alerts (e.g., 'Write the code to the named output files') that should be formalized as tool behavior documentation or output schema constraints, not embedded in the description. This bleeds implementation details into the LLM prompt.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
No output schemas are documented for any tool. LLMs cannot plan downstream calls or extract generated code references without knowing what fields are returned (e.g., file paths, generated code snippets, compilation errors).
No error handling or recovery guidance. If code generation fails, returns a duplicate DDD component, or has validation errors, the tool provides no actionable error message or suggestion for the agent to correct the input and retry.
Tool interdependencies are not documented. An LLM does not know that generateEntity and generatePostgreSQLRepository work together (entity → repository), or that generateValueObject is a prerequisite for certain entities. Interdependency guidance is missing from descriptions.
Parameter descriptions are sparse or absent. For generatePostgreSQLRepository and generateDynamoDBRepository, complex nested objects (indexes, attributes, methods) lack descriptions explaining what each sub-field controls. E.g., 'composite' under 'pk' is not described.
No idempotency guarantees or confirmation patterns. These tools perform WRITE operations (generating and potentially writing files) but do not document whether repeated calls with the same input produce the same result, or whether they require confirmation before overwriting existing artifacts.