Critical gaps across all dimensions. Tool definitions are inferred from test files rather than explicit registration code. No input schemas visible in source, only parameter names and types listed in test assertions. Descriptions are present but generic (10-50 chars), lacking LLM-optimized guidance on WHEN to use each tool or what happens. Parameters lack type constraints (enums, ranges, formats). No output schemas documented. Error handling and recovery guidance absent. This server does not meet production quality baselines.

• Locate and provide explicit tool registration code (likely in Rust crates/burp-mcp/src or crates/burp-tools/src). Show JSON Schema definitions for all 15 tools with type, description, and constraint declarations for every parameter.
• Expand descriptions to 50 - 200 characters. For each tool, answer: (1) What does it do? (2) When should the LLM call it instead of a similar tool? (3) What does it return? Example: 'Read proxy history entries with optional filtering by URL, method, or status. Use this to find past requests before replaying or analyzing. Returns paginated list of requests with timestamps and response codes.'
• Document output schemas for all tools. For paginated tools, specify: total_count, next_cursor, items array with field names and types. For read tools, list all returned fields (e.g., request_id, url, method, status_code, timestamp). For write tools, confirm what was modified and return the updated resource ID.
• Add parameter constraints: enums for status_filter (e.g., 200, 301, 400, 500), method_filter (GET, POST, PUT, DELETE, PATCH), color (red, orange, yellow, green, blue, purple). Add ranges for limit (1 - 100), page (1+). Add format hints for url_filter (regex or glob pattern).
• Implement confirmation or dry-run for irreversible operations. For lifecycle.restart, editor.patch, logger.clear, and scanner.issues.update, add a 'confirm' parameter or return a confirmation token that must be passed in a follow-up call. Document that these operations cannot be undone.