This server has critical definition gaps across nearly all tools. While tool names follow verb_noun convention (compile_sleeve, inspect_active_state, search_blocks), descriptions are present but lack actionable detail for LLM selection. Most critically: input parameters lack type definitions in visible schemas, all 10 tools accept 'object' or 'string' types with minimal constraint documentation. No output schemas are documented. Parameters like 'sleeve' and 'active_context' are described as objects but lack field-level documentation, forcing LLMs to guess structure. Error handling is absent from all tool definitions. The server appears to be a domain-specific cognitive framework (UMG/MOLT blocks) but fails to expose that domain knowledge through proper parameter constraints, enums, or structured guidance.

• Add field-level JSON Schema for all object parameters. For 'sleeve', document required fields: sleeve_name (string), neoStacks (array of NeoStack objects with name, gates, neoBlocks). For 'active_context', document: signals (array of strings), raw (object). Use $ref to avoid repetition.
• Convert purpose and block_type parameters to enums. Define: purpose enum = [debug, research, plan, govern, create, audit]; block_type enum = [TRIGGER, DIRECTIVE, INSTRUCTION, SUBJECT, PRIMARY, PHILOSOPHY, BLUEPRINT, PERSONA, AIM, USE, NEED].
• Document output schemas for all tools. E.g., compile_sleeve returns {sleeve_name, neoStacks, compilation_metadata}; search_blocks returns {results: [{name, type, description, authority_rank}], total_count, limit}.
• Add error handling guidance to tool descriptions. E.g., compile_sleeve: 'Returns error if intent is empty or no matching blocks found. Suggest refining intent or calling search_blocks to explore available blocks.'
• Expand parameter descriptions with constraints and examples. E.g., intent: 'Plain language description (50-500 chars) of desired sleeve behavior. E.g., "Debug a race condition in the scheduler by tracing causality and measuring against baseline."'