Server has 5 read-only tools with clear verb-noun naming (get_*, list_*). All tools have descriptions (avg 180 chars, within baseline 194). Input schemas are present with type declarations and descriptions. Parameter descriptions lack format constraints (e.g., date format stated in description but no regex/pattern in schema). Error handling is minimal; no recovery guidance or actionable error messages. No tool annotations (readOnlyHint, etc.). Composition is sound, tools are single-responsibility and chainable. Security: credentials injected via env vars (good), but no audit logging or permission gates documented.

• Document output schemas for all 5 tools. Example for get_weekly_schedule: {type: 'object', properties: {week: {type: 'number'}, classes: {type: 'array', items: {type: 'object', properties: {id, name, time, instructor, capacity, booked, ...}}}}}. This enables LLMs to extract and chain data.
• Add JSON Schema format/pattern constraints to date parameters. Change 'start_date' schema from {type: 'string', description: '...'} to {type: 'string', format: 'date', pattern: '^\d{4}-\d{2}-\d{2}$', description: '...'}.
• Implement structured error responses with recovery hints. Example: {error: 'Invalid date range', message: 'start_date must be before end_date', suggestion: 'Try get_weekly_schedule(week_offset=0) for the current week.'}
• Add readOnlyHint: true to all 5 tool definitions to signal to clients that these are safe, non-mutating operations.
• Refactor get_wod to always require programme_ids (or make it a separate discovery tool). Current fallback to returning programmes when none specified mixes concerns, split into get_wod(programme_ids) and list_programmes().