Two tools with reasonable descriptions but critical schema gaps. meta_search has a complete input schema with proper types and descriptions (query, kind enum, limit). meta_invoke also has a complete schema (id, kind enum, args object). However, NEITHER tool documents its output schema, LLMs cannot plan downstream calls or extract required data without knowing what fields are returned. Descriptions are adequate (100-150 chars) but lack actionable context on when to use each tool vs alternatives. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). meta_invoke is a write operation but lacks confirmation/dry-run pattern. Tool names are reasonable (verb_noun style) but 'meta_' prefix is domain-specific jargon that doesn't clearly convey action to LLMs unfamiliar with the capability-menu system.

• Document the complete output schema for meta_search: return an array of objects with fields like {id, name, description, kind, schema, tags, classification_status}. Include example output.
• Document the complete output schema for meta_invoke: return {success: boolean, result?: any, error?: {code, message, recovery_hint}}. Clarify what 'result' contains for tools vs skills.
• Rename tools to action-verb style: search_capabilities (or search_tools_and_skills) and invoke_capability. This improves LLM intent inference.
• Add error handling guidance to meta_invoke: 'If tool execution fails, the error response will include a recovery_hint. For permission errors, ask the user. For invalid args, call meta_search to verify the tool schema first.'
• Add tool annotations: mark meta_search as readOnlyHint=true; mark meta_invoke as destructiveHint=true (since it can execute write operations) and require explicit user confirmation before invoking tools with side effects.