Two tools with well-structured schemas and comprehensive descriptions. natural_language_query has excellent parameter documentation (question, allowed_entities, blocked_columns, max_rows, offset) with type constraints and clear purpose. list_entities is minimal but functional. Both tools are READ_ONLY and properly scoped. Descriptions exceed 100 chars and explain WHAT/WHEN/WHY. However, output schemas are not explicitly documented in the tool definitions, only input schemas are visible. Error handling guidance is present in descriptions but not formalized in error response patterns. Tool composition is sound (discovery → query pattern). No security issues detected (no secrets in params, server-side config injection via env vars).

• Document output schemas for both tools. For natural_language_query, specify: 'Returns {success: boolean, rows: Array<{[columnName]: any}>, rowCount: number, executedQuery?: string}'. For list_entities, specify: 'Returns {entities: Array<{name: string, columns: Array<{name: string, type: string}>, associations: Array<{name: string, target: string}>}>}'.
• Expand list_entities description to 150+ chars: 'List all queryable CDS db-layer entities, their columns, and available associations. Call this first to explore the schema and understand what data is available before constructing natural language queries.'
• Add formal error response patterns. Document: 'On authorization failure: returns {success: false, error: "Entity X not in MCP_ALLOWED_ENTITIES", retryable: false}. On query syntax error: returns {success: false, error: "Could not parse query: ...", retryable: true, suggestion: "Try asking: ..."}'.
• Clarify max_rows/offset interaction with server config. Add to description: 'max_rows cannot exceed server MCP_MAX_ROWS (default 50). offset cannot exceed server MCP_MAX_OFFSET. If violated, returns error with actual limits.'
• Add tool annotation hints (readOnlyHint: true) to both tools in registration to signal to clients that these are safe, non-destructive operations.