The server defines 27 tools with explicit schemas and descriptions. Most tools follow verb_noun naming (e.g., fabric_cve_scan, git_steer_repo_list) and have basic parameter schemas. However, there are significant gaps: (1) Many parameter descriptions are missing or generic. For example, fabric_cve_scan's 'repos' parameter has a description, but many tools like fabric_git_get_file lack detailed descriptions for every parameter ('ref' is underdescribed). (2) Output schemas are not documented, the code shows input schemas but no documentation of what each tool returns, which violates the pattern:tool requirement. (3) Error handling is absent from tool descriptions, no guidance on what to do when a CVE lookup fails or a repo is not found. (4) Some tools expose infrastructure concerns that should be abstracted: fabric_cve_queue and fabric_cve_stats reference internal state file 'state/cve-queue.jsonl', leaking implementation details. (5) The fabric_* tools are described as '[git-fabric]' prefixed, which is metadata noise in descriptions; the description should explain what the tool does for the user. Parameter validation rules and constraints (e.g., days_stale range, limit max value) are not consistently documented in descriptions. By baseline, average tool description is 194 chars and avg params per tool is 4; this server's descriptions average ~140 chars and are functional but sparse. Most tools lack the 'actionable context' pattern (when to use this vs. similar tools).

• Add output schema documentation to every tool. Example for fabric_cve_scan: 'Returns: {success: boolean, queued_count: number, findings: Array<{cve_id, repo, severity}>}'. This is non-negotiable for LLM planning.
• Remove '[git-fabric]' prefix from descriptions. Rewrite as user-focused intent. Example: 'fabric_cve_scan' → 'Scan one or more GitHub repositories for known vulnerabilities using GitHub Advisory Database. Results are queued for processing by the security remediation workflow.'
• Document all parameter constraints in descriptions. Example: 'days_stale (number): Minimum days since last commit to mark a branch as stale (1-365, default 30). Used to identify merged branches for cleanup.'
• Add recovery guidance to all descriptions. Example for fabric_cve_enrich: 'Fetches details from NVD. Returns severity, CVSS score, CWE references. If CVE is not in NVD yet, call again in 24 hours, the database updates daily.'
• Implement dry-run confirmation for destructive tools. Add a 'confirm' boolean param to git_steer_branch_reap and fabric_git_delete_branch. When confirm=false (default), return a preview of what would be deleted and require an explicit confirm=true call.
• Split high-cardinality tools into separate discovery and action tools. Example: 'fabric_cve_stats' is read-only discovery; separate 'fabric_cve_remediate' as the action tool so agents understand sequencing.
• Add 'next_cursor' or 'has_more' to paginated response documentation so LLMs know when to call again.
• Validate inputs and return actionable error messages. Example: if 'severity_threshold' is invalid, return 'Invalid severity: got "foo", must be one of: CRITICAL, HIGH, MEDIUM, LOW' instead of a generic 400 error.