Server has 7 tools with complete schemas and descriptions. Naming follows verb_noun convention (list_, get_, create_, update_). Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Critical gap: all tools accept 'service' parameter as injected object, this is server-side injection (good), but parameter descriptions are minimal. Output schemas are not documented. Error handling is absent from visible code. Tool composition is reasonable but lacks pagination guidance in descriptions.

• Document output schemas for all tools. Example: 'Returns {script_id: string, title: string, files: [{name: string, type: string, source: string}], created_time: ISO8601}'. This enables LLMs to chain calls.
• Expand tool descriptions to 100-150 chars with WHEN guidance. E.g., 'Retrieves complete project details including all source files. Use this to inspect all files at once; use get_script_content for a single file.'
• Add error recovery hints to descriptions. E.g., 'If script not found, call list_script_projects to verify the script_id exists.'
• Document pagination behavior: 'Returns up to page_size results. If more exist, use page_token from response to fetch next page. Total count not provided; iterate until page_token is null.'
• Mark destructive tools with idempotency guidance. E.g., 'Creating a project with the same title twice will create two separate projects. Idempotent: No. Recommend storing script_id after creation.'

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

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