Loading ToolBench
MCP server that makes AI agents get SAP CAP/CDS right: modern scaffolding + real validation loop against cds compile
CAPforge demonstrates solid domain-specific tool design with clear naming (verb_noun pattern: cap_scaffold_entity, cap_validate, ui5_scaffold_section) and comprehensive parameter schemas using Zod. All 9 tools have descriptions and input schemas visible in server.js. However, descriptions are inconsistent in depth, some exceed 200 chars (cap_scaffold_entity at ~280), while others are terse (cap_lint at ~90). Output schemas are not documented; tools return unstructured text/JSON without field-level documentation. Error handling is minimal, no recovery guidance, categorization, or actionable error messages. Parameters lack validation constraints (e.g., no min/max for numeric fields, no regex patterns for paths). The server includes a prompt (cap_workflow) and resource (conventions://cap) that guide agent behavior, which is excellent for composition, but tool-level error recovery is absent.
Runs `cds deploy --dry-run` on the project (SQLite in-memory) to validate the entire stack: model compile, service definitions, and CSV data load. Returns errors if any layer fails.
Runs `cds lint` on the project and returns style/best-practice warnings. Complements cap_validate (which checks syntax); this checks conventions.
Reads the CAP project structure and returns the existing namespaces, entities, services, and files so the agent can reuse exact names and avoid conflicts.
Generates the complete scaffolding of a CAP entity following the loaded conventions: CDS model, service projection, annotations.cds (labels + UI.LineItem), mock CSV header and i18n bundles (English base plus one file per requested locale). Returns the content so you write it with cap_write_files and validate it with cap_validate.
The validation loop. Runs `cds compile` on the project and returns the errors so the agent can fix them. A clean compile means the model is syntactically correct and all references resolve.
Output schemas not documented. Tools return unstructured text (e.g., cap_scaffold_entity returns 'content' as string; cap_project_context returns 'namespaces', 'entities', 'services' but field types/structure undefined). LLMs cannot plan downstream calls or extract structured data reliably.
Error handling lacks recovery guidance. Tools call external CLIs (cds compile, cds lint, cds deploy, ui5/linter) but do not categorize errors as retryable/user-fixable/fatal or provide actionable next steps. E.g., cap_validate returns raw compile errors without suggesting which tool to call next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Writes one or more files into the given CAP project. Creates folders when missing.
Runs `@ui5/linter` on the UI5 app and returns style/best-practice warnings.
Generates a UI5 fragment (XML) for a table or form section, with data binding, columns/fields, and event handler stubs. Returns the XML so you write it with cap_write_files and validate with ui5_validate_view.
Validates a UI5 XML fragment against its controller: checks that all event handlers are defined, binding paths are valid, and XML is well-formed.
Parameter constraints missing. Numeric fields (e.g., 'length' in cap_scaffold_entity.fields[].length) lack min/max bounds. String paths (projectPath, xmlPath, controllerPath) lack format validation or traversal guards. No regex patterns or length limits documented.
Descriptions vary in depth. cap_scaffold_entity (~280 chars) is thorough; cap_lint (~90 chars) is terse. Inconsistency makes some tools harder for LLMs to select. Baseline for A+ tools is 50-200 chars with clear WHAT/WHEN/WHY.
No idempotency guarantees documented. cap_write_files overwrites files; cap_scaffold_entity generates content. Agents may retry on transient failures, risking duplicate writes or lost edits. No idempotent hints or confirmation patterns.