28 tools with consistent naming (rtg_ prefix + verb_noun pattern) and descriptions present. However, parameter descriptions are generic ('Optional X options') lacking actionable constraints. Input schemas visible but sparse, most complex params like 'graph_changes', 'knowledge_changes', 'anchor_records' are typed as 'object' or 'array' with no nested schema detail. Output schemas not documented. Error handling present in code but not surfaced in tool definitions. Tool annotations loaded from manifest (readOnlyHint, destructiveHint) but not visible in source schema definitions provided.

• Expand parameter descriptions from generic placeholders to actionable constraints. Example: 'validation_mode' should be 'Validation mode: strict (default, rejects invalid changes) or lenient (allows warnings). Use strict for production, lenient for exploratory changes.'
• Document nested schema for complex object/array parameters. For 'graph_changes', define: {type: object, properties: {nodes: {type: array, items: {type: object, properties: {id, type, attributes}}}, edges: {...}}}. Use JSON Schema $ref for reusable structures.
• Add output schema documentation to every tool. Include example response structure, field types, and which fields are safe to chain to downstream tools. Example: 'Returns {migration_id: string, status: enum[staged|applied|failed], created_at: ISO8601, errors: array[{code, message}]}'.
• Implement dry-run variants or confirmation prompts for WRITE and IRREVERSIBLE tools. For rtg_restore_system_snapshot, add a 'confirm' parameter (boolean, default false) that requires explicit true to proceed. Document: 'This operation is irreversible. Set confirm=true only after verifying the snapshot ID.'
• Validate and document enum constraints for string parameters. For 'validation_mode', declare enum: [strict, lenient] in schema. For 'status' filters, enumerate valid values (staged, applied, failed, abandoned). Prevents LLM hallucination of invalid values.