This collection exhibits pervasive quality gaps across 27 tools. Most tools lack proper input schemas (many inferred from descriptions only), descriptions are generic or missing context, and parameter documentation is sparse. The 'add' tool has a basic schema but no error handling. Tools like 'convert_video', 'read_dir', and 'list_roots' show context-aware logic but lack output schema documentation. GitHub/Azure DevOps/SonarQube tools have better descriptions but missing parameter constraints (enums for 'state', 'status', 'severities'). No tool declares permissions, supports dry-run, or provides recovery guidance. Composition is poor: 'list_pull_requests' appears twice with different signatures (GitHub vs Azure), inviting LLM confusion. Average tool description ~120 chars (below 194 baseline); many parameters lack type hints or descriptions.

• Rename Azure DevOps tools with a prefix (e.g., 'ado_list_pull_requests', 'ado_get_pull_request') to avoid collision with GitHub equivalents. This makes tool selection unambiguous.
• Document output schemas for all tools. For example, 'get_repository returns {id, name, url, owner, created_at}' so LLMs know what fields are available for downstream calls.
• Convert free-form string parameters to enums where applicable: 'state' → enum [open, closed, all]; 'severities' → enum [BLOCKER, CRITICAL, MAJOR, MINOR, INFO]; 'format' → enum [mov, avi, mkv, webm].
• Add error recovery hints to tool descriptions. E.g., 'If the file is not found, call search_files() with a partial name.' This guides multi-step planning.
• Implement dry-run or confirmation for destructive tools. E.g., add a 'confirm' parameter to edit_doc_contents and convert_video, or create separate 'preview_*' tools that show what would change before committing.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry