Server has 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (originality_scan, originality_batch_scan, originality_scan_url, originality_get_scan_results, originality_get_credit_balance). Descriptions are present and substantive (100-200 chars typical). However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are good but lack format constraints (e.g., no min/max for content length, no guidance on URL format). Error handling is minimal: client.ts throws generic API errors without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Batch tool is well-designed but lacks pagination/limit guidance for large result sets.

• Document output schemas for all tools. Example: originality_scan returns {scanId, status, results: {ai_score, plagiarism_matches, readability_score, ...}, credits_used}. Include field types and descriptions.
• Enhance error handling in client.ts. Categorize errors: 'Invalid API key' (user-fixable, suggest checking ORIGINALITY_API_KEY), 'Rate limited' (retryable, suggest exponential backoff), 'Content too large' (user-fixable, suggest splitting content). Return structured {error, code, recovery_hint}.
• Add tool annotations via MCP SDK. Mark all tools with readOnlyHint=true. Mark originality_batch_scan with idempotentHint=true. This signals to LLMs that these are safe to retry.
• Add parameter constraints. Specify: content max length (e.g., 100,000 chars), title max length (e.g., 255 chars), optimizerCountry as ISO 3166-1 alpha-2 code, optimizerQuery max length (e.g., 100 chars). Use descriptions like 'Plain text content to analyze (max 100,000 characters)'.
• Document batch limits. Add to originality_batch_scan description: 'Process up to 50 items per request. For larger batches, split into multiple calls.' Return per-item success/failure in response so partial failures are visible.