The cladding server exposes 27 tools across spec verification, feature management, and assurance workflows. While all tools have descriptions and input schemas are visible, the quality is inconsistent. Tool names follow a consistent prefix pattern (clad_*) but lack clear verb_noun conventions, e.g., 'clad_prepare_init' vs 'clad_init' conflates preparation with execution without clarity on when each is called. Parameter descriptions exist but are minimal (typically 10-40 chars), failing to explain dependencies, constraints, or when the tool should be invoked. Output schemas are not documented anywhere in the visible code, LLMs cannot infer what fields are returned. Error handling is not visible. Security around destructive operations (clad_init, clad_edit_spec, clad_create_feature) lacks confirmation or dry-run patterns. The server exposes workflow-heavy concerns (onboarding, clarification cycles) that would benefit from structured output and error recovery guidance. STDIO transport caps this at 50 maximum; architecture prevents remote hosting.

• Document output schema for all 27 tools. For each tool, add a structured description of returned fields, types, and meanings. E.g., clad_get_feature should return {id, title, body, status, linked_capabilities: []}.
• Expand parameter descriptions to 50-100 chars with actionable constraints. Replace 'User intent for initialization' with 'User intent for initialization (required; guides onboarding questions; e.g., "add-type-safety" or "migrate-framework").'
• Consolidate prepare/stage/execute workflows into clear tool chains with documented state transitions. E.g., rename clad_prepare_init → clad_draft_init (returns proposal), clad_stage_init → clad_review_init (accepts user feedback), clad_init → clad_apply_init (executes with confirmation). Document in each description the prior step.
• Add confirmation parameters or a separate dry-run mode for all WRITE tools. E.g., clad_create_feature(id, title, body, cwd, dry_run=false), when dry_run=true, return the spec delta without modifying state.
• Define explicit error responses for each tool. Document what errors can occur, what they mean, and what recovery action the LLM should take. E.g., clad_create_feature: 'If error.code === DUPLICATE_ID, call clad_get_feature(id) to inspect the existing feature.'
• Convert inline enum values (tier: 'pre-commit, pre-push, all') into formal JSON Schema enums for clad_run_check, clad_run_gate, and any tool with fixed parameter values.
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to each tool registration to signal intent to the MCP client and LLM.