aos exposes only 2 tools with minimal schema definition. The 'commands' tool has a basic boolean-parameter schema, but the 'version' tool has an empty input schema. Descriptions are present but generic (e.g., 'Print the version of aos' is 26 chars, below the 50-char baseline for LLM optimization). No output schemas are documented. Tool definitions appear inferred from test/dispatch files rather than explicit MCP registration, capping per-tool scores at 50. No error handling guidance, no parameter validation hints, and no composition support for chaining tools.

• Explicitly register tools with the MCP framework using a proper tool registration API (e.g., server.tool() or equivalent). Ensure tool definitions are visible in the main server initialization code, not inferred from test files.
• Add comprehensive output schemas for both tools. Document what fields 'commands' returns (e.g., command_name, description, platform, group) and what 'version' returns (e.g., version_string, build_date, commit_hash).
• Expand 'version' description to 50 - 150 chars: 'Retrieve the installed version of aos, including build metadata and commit hash. Use this to verify installation or report bugs.'
• Add error handling guidance: 'If a command is not found, call commands with --all flag to list all available commands. If version resolution fails, check that aos is properly installed.'
• Document parameter constraints in descriptions. For 'commands' tool, clarify what --all, --json, and --check do and when each is useful.