drift-guard has 5 tools with complete input schemas and descriptions, but quality is uneven. All tools have descriptions (10 - 200 chars, within baseline), and schemas are properly typed with required fields. However, parameter descriptions are sparse or generic. drift_guard_check has an optional nested object (evaluationResult) with undocumented sub-properties (score, violations array items). Output schemas are not documented anywhere, LLMs cannot predict what these tools return. Error handling is present but generic (catch-all try/catch returning JSON errors). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE vs READ_ONLY). Naming is verb-noun compliant (drift_guard_*), but descriptions lack WHEN/WHY context and dependency hints. Parameter descriptions are minimal: 'Absolute path to the project root' appears 4 times verbatim, and 'File paths to track' lacks format guidance. No pagination, no result limits documented, no chaining IDs in responses. Composition is reasonable (each tool has one job), but no evidence of idempotency or batch operations.

• Document output schemas for all 5 tools. Specify the structure of CheckResult, QualityReport, SessionReport, and TrackEntry (visible in types.ts imports but not in tool definitions). Include field names, types, and descriptions so LLMs know what to extract.
• Add tool annotations: mark drift_guard_init and drift_guard_save with destructiveHint=true (they write to .drift-guard/); mark drift_guard_track, drift_guard_check, drift_guard_report with readOnlyHint=true. This enables agents to reason about retry safety.
• Enhance parameter descriptions with format and constraint details. E.g., 'files: Array of file paths relative to projectRoot (e.g., ["src/main.ts", "README.md"]). Supports glob patterns. Max 100 files per call.' Replace generic 'Absolute path to the project root' with 'Absolute filesystem path to the project root (e.g., /home/user/my-project). Must be readable and contain a CLAUDE.md or .drift-guard/ directory.'
• Implement structured error responses with recovery guidance. Instead of {error: message}, return {error: message, code: 'INVALID_PATH'|'NOT_FOUND'|'PERMISSION_DENIED', retryable: boolean, suggestion: 'Try calling drift_guard_init first'}. This guides agent retry logic.
• Document idempotency guarantees. Clarify whether drift_guard_init is safe to call multiple times (idempotent) or if it resets state. Clarify whether drift_guard_track appends to history or replaces it. Agents need this to plan safely.