Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Both tools accept file paths and numeric thresholds with defaults, but lack detailed guidance on expected formats, error conditions, and output structure. Descriptions are present but generic (under 100 chars). No parameter descriptions visible in schema. No error handling guidance. Tools are read-only (good) but lack idempotent/readonly annotations.

• Add parameter descriptions to the JSON Schema input objects. For snapshot_path: 'Path to a JSONL file containing embedding records. Each line must be valid JSON with {id, vector: number[], text} fields.' For dup_threshold: 'Cosine similarity threshold (0.0 - 1.0) for detecting duplicate vectors. Default 0.999 flags near-identical embeddings.'
• Document the output schema. Both tools return JSON with fields like 'ok' (boolean), 'record_count' (integer), 'dimension' (integer), 'findings' (array of {severity, code, message}). Provide this structure in the tool description or as a separate schema reference.
• Expand tool descriptions to 80 - 150 characters with clear intent. Example: 'Audit a JSONL embedding snapshot for data quality issues: duplicate vectors, dimension mismatches, zero-norm vectors, and retrieval domination. Returns findings with severity levels (critical/warning) and actionable codes.'
• Add error handling guidance. Document that file-not-found returns a specific error; malformed JSONL returns a line number and parsing error; empty files are rejected. Include recovery hints: 'If the file path is relative, ensure it is relative to the working directory where the MCP server runs.'
• Add readOnlyHint: true to both tool definitions in the MCP schema to signal that these tools do not modify state and are safe to call multiple times.