Meridian MCP has critical definition quality gaps across all dimensions. Tool names are somewhat descriptive (verb_noun pattern present: ListClustersTool, GetClusterTool, CreateClusterTool, etc.), but the source code provided does NOT include actual tool registration details, parameter schemas, or descriptions beyond the brief summary in the metadata. No input schemas are visible in the provided source. All 19 tools have only 1-3 word descriptions ('List clusters', 'Get a single cluster by name', etc.) which fall well below the 10-1024 character baseline and provide minimal guidance on WHEN to use a tool vs similar ones (e.g., GetClusterTool vs ListClustersTool distinction is unclear from description alone). No parameter-level descriptions visible. No documented output schemas. The Makefile and Dockerfile snippets confirm this is a Go/mark3labs/mcp-go project, but the actual tool definitions from mcp/internal/tools/*.go files are not provided. Since input schemas, parameter descriptions, and detailed tool descriptions cannot be verified in the source, all per-tool schema and description scores are severely penalized per the HARD RULES.

• Expand all tool descriptions to 50 - 200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and any prerequisites. Example: 'List all available Meridian clusters with details (name, status, pool membership). Use this to discover clusters before operating on specific ones. Returns pagination metadata for browsing large cluster inventories.'
• Add structured input schema definitions with explicit type, description, and constraint information for all parameters. For example, cluster_name should have type string, required flag, and a description like 'Unique cluster identifier (1-64 alphanumeric chars and hyphens). Must exist in the system.'
• Document all output schemas. For ListClustersTool, specify that it returns {clusters: [{name: string, status: string, pool_id: string, ...}], total_count: integer, next_cursor?: string}. For GetClusterTool, specify exact fields returned.
• Add parameter-level descriptions to every input field. Do not assume names are self-documenting. E.g., a 'replica_count' param in ScalePoolTool should say 'Target number of cluster replicas (1-100). Scaling down may evict running workloads.'
• Implement and document confirmation patterns for destructive tools (DeleteClusterTool, RemoveCatalogTool, PromoteEnvironmentTool). Add a 'confirm' parameter or a separate 'confirm_delete_cluster' tool that returns a confirmation token, which the deletion tool then requires.
• Add explicit error handling with recovery guidance. For GetClusterTool, document: 'If cluster not found, returns {error: "cluster_not_found", available_clusters: [...]}. Use ListClustersTool to discover cluster names.'