The server defines 4 tools with partial schema coverage. The primary tool 'orbit' has a well-structured input schema (cmd, args, snapshot, format) with type definitions and descriptions, but lacks documented output schema. Three supporting tools (orbit_policy_get, orbit_policy_set, orbit_export_changeset) have minimal or missing parameter descriptions. Tool descriptions are present but generic, they state WHAT the tool does but lack WHEN to use it or what the LLM should expect in return. No tool descriptions explain error recovery paths or prerequisites. Parameter descriptions are sparse: 'Optional command arguments' and 'Policy configuration object' are too vague for LLM reasoning. The codebase shows sophisticated internal logic (ChangesetService, PolicyEngine, SnapshotRepo) but this complexity is not surfaced in tool contracts, forcing LLMs to guess at semantics.

• Document the output schema for each tool. E.g., 'orbit returns {success: boolean, result?: object, error?: string, command_help?: string}' so LLMs know what fields to extract.
• Expand parameter descriptions with constraints and examples. E.g., 'args: object with keys like {pageSize: 1-100, filter: string, sortBy: "name"|"date"}' instead of 'Optional command arguments'.
• Add recovery guidance to tool descriptions. E.g., 'If cmd fails with 429, retry after 60s. If 400, check args format. Call cmd=help for valid commands.'
• Clarify the role of orbit_policy_get/set relative to orbit. Are they for advanced users? Prerequisites? Add a sentence like 'Use this to inspect/override policy before running orbit commands.'
• Implement per-parameter validation with actionable error messages. E.g., 'Invalid cmd: got "foo", valid commands are: help, list, query, edit, apply, rollback' instead of a generic error.