Ziplex provides 9 read-only tools with consistent naming (verb_noun pattern: get_*, list_, search_) and complete input schemas. All tools have descriptions (avg ~60 chars, baseline 194). However, descriptions are terse and lack context on WHEN to use each tool or dependencies between them. Parameters are typed but many lack detailed constraints (e.g., confidence_below has no range guidance). Output schemas are not documented, LLMs cannot predict response structure for chaining. No error handling guidance, no examples of failure modes. Tool composition is sound (each does one thing), but descriptions read like API stubs rather than LLM-optimized prompts.

• Document output schemas for all 9 tools. For each, specify: field names, types (string, number, array, object), nesting, and what each field represents. Example: 'Returns {overview: {total_files: number, total_tokens: number, languages: [string]}, ...}'.
• Expand descriptions to 100 - 200 chars (baseline 194). Add WHEN to use: 'Get file relationships to understand dependencies before refactoring. Use get_dependents to find files that import this file; use get_blast_radius to find all files affected by changes to this file.'
• Add min/max constraints to numeric parameters. E.g., 'confidence_below: number (0.0 - 1.0, default 0.5), filter files with confidence score below this threshold' and 'max_results: integer (1 - 1000, default 100)'.
• Document error cases and recovery paths. E.g., 'If aif.json is missing or stale, call check_freshness() first. If a file is not found, search_project() to locate it by pattern.'
• Clarify default behavior for optional parameters. E.g., 'If aif_path is omitted, uses the server's configured default (set via environment or config file). If project_path is omitted, uses the project root from aif.json.'