14 tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have names starting with action verbs (portal_*) and descriptions (10-100 chars), meeting baseline naming conventions. However, many parameters lack descriptions or have minimal ones (e.g., 'episodeDir' described only as 'Episode directory path (optional)' without format/path constraints). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance or categorization. Tool composition is reasonable (each does one thing), but parameter relationships are underdocumented (e.g., episodeId vs episodeDir mutual resolution logic not explained). Zod schemas present but descriptions do not reference constraints (regex patterns, length limits, enum values) in human-readable form.

• Document output schemas for all 14 tools. For each, specify: response object structure, field types, pagination (if applicable), and example response. Use a consistent format (e.g., 'Returns: {success: boolean, data: {...}, error?: string}').
• Expose Zod constraints in parameter descriptions. For 'channel', change description from 'kebab-case channel slug (optional)' to 'kebab-case channel slug, 2-64 chars, lowercase letters/digits/hyphens only (optional)'. For 'note', add 'max 500 characters'.
• Clarify parameter relationships. For tools accepting both episodeId and episodeDir, add: 'Provide either episodeId (UUID) or episodeDir (path). If both provided, episodeId takes precedence. If neither, channel is required to infer the episode.'
• Add error handling guidance to tool descriptions. Example: 'On 404 (episode not found), try portal_storyboard_list() to find the correct episodeId. On 409 (conflict), call portal_episode_revisions() to check the latest baseRevisionNo.'
• Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote client access and hosted deployment scenarios.