This monorepo contains 16 tools across file-browser and confluence packages. Across the codebase, tools exhibit consistent structural patterns but significant quality gaps: most tool descriptions are present but minimal (often single sentences with no context on when to use them or what parameters control), parameter descriptions are sparse or absent, and input/output schemas are not explicitly visible in the provided code excerpts. The file-browser package exposes 9 tools for filesystem operations (write-file, open-file, list-directory, tree-directory, mk-dir, remove-file, move-path, find-or-replace, patch-file), while the confluence package exposes 7 tools (open-page, search-cql, search-pages, list-pages-of-space, list-spaces, create-page, update-page). Tool naming follows a consistent verb_noun pattern (e.g., write-file, open-file, list-directory), which is good. However, critical details are missing: (1) parameter descriptions are not visible in the provided code, making it impossible to verify schema completeness; (2) output schemas are not documented in the excerpts; (3) error handling and recovery guidance are absent; (4) destructive operations (remove-file, write-file with overwrite) lack confirmation/dry-run patterns; (5) tools like find-or-replace and patch-file have high risk but minimal documentation. Since code was not fully provided, many tool definitions are inferred rather than directly visible, which caps individual tool scores at 50 per the hard rules.

• Document all input and output schemas explicitly in tool registration. Include parameter types (string, number, boolean, enum), constraints (min/max length, regex patterns), and required/optional flags. Output schemas should list return fields, their types, and structure (e.g., pagination metadata).
• Expand tool descriptions to 50-200 characters with explicit context: WHAT the tool does, WHEN to use it instead of similar tools, and what it returns. Example: 'write-file overwrites the entire file from scratch; patch-file makes surgical edits using line numbers. Use write-file to replace content, patch-file for targeted line updates.'
• Add descriptions to every parameter. For example: filepath: 'Path to the file (absolute or relative to working directory; ./ prefix optional)', content: 'File content as a UTF-8 string (will overwrite any existing file)', pattern: 'Regex pattern to match (PCRE syntax; case-sensitive unless (?i) flag used)'.
• Implement confirmation/dry-run for destructive operations: add a confirm_delete boolean param to remove-file; add a force_overwrite param to write-file with default false; add a dry_run param to patch-file to preview changes before applying.
• Add pagination support: max_results (int, 1-100, default 20) and cursor/offset for list-directory, list-pages-of-space, list-spaces, search-cql, search-pages. Return total_count and next_cursor in responses.
• Enhance error responses with recovery guidance. Example: instead of 'File not found', return 'File not found. Did you mean: [similar_files]. Or try list-directory to explore available files.'

Inferred effective spec: 2025-06-18+.

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