Three tools with domain-specific names but significant quality gaps. All tools have descriptions (10-50 chars, below baseline 194), lack parameter descriptions, and expose complex nested objects without schema documentation. No error handling guidance, no output schemas documented, no pagination or result limits. Tool names are descriptive but descriptions are too terse for LLM selection. Parameters like 'change' are opaque objects with no inline schema visibility.

• Expand tool descriptions to 100-200 chars. Example: 'inspect_research_project: Read project metadata, validation gates, receipt chain, and next canonical routes. Use this first to understand project state before validating or committing changes.'
• Document the 'change' object schema inline. Add description: 'Canonical change specification (object) with required fields: request_id (string, unique identifier), expected_mutation_revision (integer, optimistic lock), origin_skill_id (string, source tool), artifact (string, artifact name), target_state (object, new state), state_reason (string, audit trail).'
• Add output schema documentation. Example for validate_canonical_change: 'Returns {fingerprint: string (SHA256 hash), findings: [{code: string, message: string}], is_valid: boolean}'.
• Add error handling guidance to commit_canonical_change: 'On immutable artifact error, use inspect_research_project to check artifact status. On revision conflict, retry with updated expected_mutation_revision from latest receipt.'
• Constrain project_root parameter: 'Path to research project root directory (must contain .research/ subdirectory with project.yaml and receipts/). Relative or absolute paths accepted.'