Server has 7 tools with consistent verb-noun naming (get*, all starting with 'get'). Descriptions are present and contextual (avg ~150 chars), exceeding the 10-char minimum. Schemas use Zod with type definitions and descriptions for most parameters. However, several parameters lack descriptions (e.g., domainId, external, name in getModelObjects), and output schemas are not formally documented, responses are JSON-stringified text rather than structured objects. Error handling is minimal (generic try-catch returning error.message). No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY. Composition is sound: tools chain logically (getLandscapes → getLandscape → getModelObjects → getModelObject). Parameter naming is mostly clear but could be more specific (e.g., 'external' lacks context).

• Document output schemas for all tools. Define structured response objects (e.g., {landscapes: [{id, name, description}], total: number}) instead of JSON-stringified text. Update tool descriptions to include 'Returns: {field: type, ...}'.
• Add .describe() to all Zod parameters in getModelObjects. E.g., domainId: z.union([...]).describe('Domain ID(s) to filter by. Use to scope queries to specific business domains.'), external: z.boolean().optional().describe('Filter to external systems only (true) or internal only (false).').
• Add readOnlyHint annotations to all tools. Use @readOnly decorator or metadata field to signal to LLMs that these are safe, non-destructive operations.
• Implement structured error responses. Return {error: {code: 'NOT_FOUND'|'INVALID_PARAM'|'RATE_LIMIT', message: '...', suggestion: '...'}} with actionable recovery hints. E.g., 'Landscape not found. Call getLandscapes() to list available landscapes.'
• Refine parameter naming: rename 'external' to 'isExternal' for clarity; ensure all ID parameters end with '_id' (domainId, technologyId, teamId are good; keep consistent). Add parameter constraints in descriptions (e.g., 'landscapeId: 20-character alphanumeric ID').