Server provides 5 configuration parsing tools with complete input schemas and descriptions. All tools are read-only and low-risk. However, descriptions are generic (avg 120 chars, below 194-char baseline), parameter descriptions lack actionable constraints (e.g., no format specs for version strings, no limits on content size), and output schemas are not documented. Error handling returns plain text rather than structured guidance. Tool names are descriptive but lack verb-noun clarity (e.g., 'json_config' vs 'parse_json_config'). No tool annotations (readOnlyHint) despite all being safe operations.

• Document output schemas for each tool action. E.g., json_config 'parse' returns {parsed: object, valid: boolean, errors?: string[]}. Declare these in tool descriptions or a separate schema reference.
• Add format and constraint hints to parameter descriptions. E.g., 'content: JSONC string (max 10MB, UTF-8)' and 'version_a: semantic version string (e.g., 1.2.3 or ^1.0.0)'.
• Restructure error responses as JSON objects: {error: string, code: string, recovery?: string}. E.g., {error: 'content2 required', code: 'MISSING_PARAM', recovery: 'Provide both content and content2 for merge/diff actions'}.
• Rename tools to verb-noun form: parse_json_config, parse_yaml_config, parse_toml, parse_ini, diff_configs. This clarifies intent and improves LLM tool selection.
• Add readOnlyHint: true annotation to all 5 tools in the server.tool() registration to signal safety and enable speculative execution by agents.