Five tools with complete input schemas and descriptions, but quality is uneven. Tool names lack clear action verbs (standards_audit, standards_adopt, standards_dogfood are vague about what happens). Descriptions are present but often technical and jargon-heavy, making them less useful for LLM selection. Parameters are typed but many lack actionable constraints or format guidance. No documented output schemas. Error handling and recovery guidance absent. Security concerns: standards_adopt and standards_dogfood accept file paths and perform writes, but no clear permission gates or audit trail documentation.

• Rename tools to start with action verbs: audit_standards, adopt_standards, verify_standards_dogfood, list_client_capabilities, analyze_context. This matches the verb_noun pattern and helps LLMs infer intent from the name alone.
• Rewrite descriptions in plain language. Example: standards_audit → 'Verify that a repository meets governance standards by checking manifest, lockfiles, branch protection, and hook configuration. Returns pass/fail status and list of violations.' Current description assumes domain knowledge.
• Document output schemas for all tools. Specify what fields are returned, their types, and which fields are needed for chaining to other tools (e.g., if standards_audit returns violation IDs, standards_adopt should accept them).
• Add error handling guidance to write tools (standards_adopt, standards_dogfood). Example: 'If adoption fails, the tool returns a list of blocking issues. Call standards_audit to diagnose. Use dry_run=true to preview changes before applying.'
• Add format constraints to path parameters. Example: 'path: string, confined to server root unless --allow-outside-root flag is set. Must be a valid UTF-8 relative path, no symlinks.' This prevents path traversal and clarifies security boundaries.