Server has 7 tools with clear verb-noun naming (list_, get_, create_, update_). All tools have descriptions (avg ~80 chars, baseline 194). Input schemas are present with type definitions and descriptions. However, critical gaps exist: (1) 'service' and 'chat_service'/'people_service' parameters expose injected objects without clear documentation of what they are or why LLMs should care; (2) output schemas are completely undocumented, no return type specifications visible; (3) error handling guidance is absent; (4) parameter constraints (e.g., page_size limits, enum values for space_type) lack validation rules in descriptions. Tools are well-composed (single responsibility) and naming is consistent, but descriptions are terse and lack WHEN/WHY context. Pagination support is present (page_size, page_token) but total count and next_cursor fields are not documented.

• Document output schemas for all tools. Specify return type (object/array), required fields, and field types. Example: 'Returns array of {script_id: string, title: string, created_time: ISO8601}'. This enables LLM chaining.
• Remove or hide injected service parameters from input schemas. These are server-side only and confuse LLMs. If documentation is needed, add a note in tool description: 'Service clients are injected by the server.'
• Expand parameter descriptions to 100-150 chars. Add WHEN/WHY context. Example: 'page_size (1-100, default 50): Number of results per page. Use smaller values for faster responses; larger values reduce API calls but increase latency.'
• Add error handling guidance to tool descriptions. Example: 'If script_id not found, returns 404. Call list_script_projects() to discover available IDs. Retryable: yes.'
• Document pagination return fields. Specify whether tools return total_count, next_cursor, or has_more. Example: 'Returns {items: [...], next_page_token: string|null, total_count: int}' so LLMs know when to stop.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry