Loading ToolBench
Living project context for AI agents — provides tools to explore NestJS project structure, modules, endpoints, entities, tests, and conventions
Server has 12 tools with consistent naming (verb_noun pattern: check-, list-, get-) and all have descriptions. However, descriptions are often generic or lack actionable context for LLM selection. Parameter schemas are present but descriptions are sparse, many parameters lack detail on format, constraints, or when to use them. Output schemas are not documented. Error handling is minimal; tools return plain strings rather than structured error guidance. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only. Composition is reasonable, tools are single-purpose, but chaining support is weak (no IDs returned to enable downstream calls).
Validates if a module follows project conventions (structure, naming, barrel exports)
Returns a code review checklist based on project conventions. Same content as code-review-checklist prompt.
Returns a step-by-step guide to add an endpoint. Same content as create-endpoint prompt. Output includes executable steps — agent MUST ask developer for confirmation before executing.
Returns a step-by-step guide to create a module. Same content as create-module prompt. Output includes executable steps — agent MUST ask developer for confirmation before executing.
Returns entity schema (MikroORM, TypeORM, or Objection): properties, types, relations. ORM is auto-detected from project if omitted.
Returns a guide to investigate a bug. Same content as investigate-bug prompt. Output includes executable steps — agent MUST ask developer for confirmation before executing.
Output schemas not documented. Tools return plain strings (e.g., 'Module not found') rather than structured objects. LLMs cannot parse results reliably or extract IDs for chaining.
Parameter descriptions are minimal or missing. 'moduleName' appears in 8 tools but is never described (e.g., 'user' vs 'user-module' vs 'UserModule'?). 'projectRoot' is described identically in all tools but lacks format guidance (absolute path? relative? env var fallback?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Returns full module details: structure, entities, endpoints, tests
Recent git changes (commits, files, authors)
Test summary for project or module: unit, e2e, factories, in-memory repos
Returns a step-by-step guide to update module documentation. Same content as update-documentation prompt. Output includes executable steps — agent MUST ask developer for confirmation before executing.
Lists API endpoints. Optionally filters by module.
Lists all project modules with paths, controllers, entities and documentation
No tool annotations. All 12 tools are read-only but lack readOnlyHint annotation. Guides (get-create-module-guide, etc.) mention 'agent MUST ask developer for confirmation' but no confirmation mechanism (MRTR/input_required) is implemented.
Error handling returns plain text strings ('Module not found') instead of structured error objects with recovery guidance. LLMs cannot distinguish retryable errors from user-fixable ones.
Tool descriptions lack actionable context. 'Returns entity schema' does not explain WHEN to call it vs get-module-detail, or what downstream tools consume the schema. Descriptions should guide LLM selection.