MCP server for SAP CAP: introspect the CDS model (services, entities, definitions) and search CAP documentation.
Six tools with clear verb-noun naming (compile_model, list_services, get_definition, search_docs, fetch_doc). All have descriptions (194 - 250 chars, within baseline 34 - 392). Input schemas present with type declarations and descriptions. All parameters documented. However, output schemas are not explicitly documented in the source code, only inferred from descriptions. Error handling is present but generic (CompileError, no recovery guidance). No tool annotations (readOnlyHint, destructiveHint). Risk labels in metadata indicate read-only intent but not formally declared in schema.
Compile the CAP CDS model at a project path to CSN and return a summary: counts of services, entities and types, plus service and entity names. Set raw=true to include the full CSN JSON (truncated when large). Read-only. Requires @sap/cds in the project or @sap/cds-dk available via npx.
Fetch a single CAP documentation page and return its title and cleaned readable text. Only URLs on the cap.cloud.sap host are permitted. Read-only.
Compile the model and return the full definition of one CSN artifact (entity, service or type): its elements with type and key flags, and its associations and compositions with targets and cardinality. Read-only.
Compile the model and list entities and aspects with element counts and key names. Read-only.
Compile the model and list CAP services with the entities each exposes. Read-only.
Search the CAP documentation (capire). Best effort: capire does not expose a stable public search API, so this ranks a curated set of documentation pages by relevance to the query, fetches the top pages and returns title, url and a snippet for each. The response is honest about how results were obtained. Read-only network access to cap.cloud.sap only.
Output schemas not documented in source code. Tool descriptions mention what is returned (e.g., 'counts of services, entities and types, plus service and entity names') but formal JSON Schema output definitions are absent. LLMs cannot reliably extract fields or plan downstream calls without explicit output schemas.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema. Risk metadata exists in evaluation metadata but not in the MCP tool definition. Agents cannot determine idempotency or safety from the tool schema alone.
Error handling lacks recovery guidance. CompileError and network errors are thrown but do not include actionable next steps (e.g., 'Try search_docs() to find CAP documentation on this error'). Errors should guide the LLM toward resolution.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
search_docs and fetch_doc accept unbounded 'limit' and 'maxChars' parameters. While minima and maxima are declared (limit 1 - 10, maxChars 1 - 200000), the descriptions do not explain the rationale or default behavior clearly. Defaults should be stated in descriptions.
fetch_doc URL validation is host-restricted ('Only URLs on the cap.cloud.sap host are permitted') but this constraint is not enforced via JSON Schema pattern or enum. Validation happens at runtime; LLMs cannot see the constraint in the schema.