Server has 7 tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (burp_target_overview, burp_live_poll, burp_flow_get, burp_replay_flow, burp_send_raw_request, burp_rule_upsert). Descriptions range 80 - 180 chars, meeting the 10 - 1024 baseline. However, parameter descriptions are sparse or missing context. burp_rule_upsert lacks enum validation for 'action' in the schema (only in description). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance. Security concern: burp_send_raw_request and burp_replay_flow allow arbitrary HTTP mutations without dry-run or confirmation, risking unintended side effects.

• Document output schema for each tool. Example for burp_flow_get: 'Returns {flowId: string, method: string, host: string, path: string, statusCode: number, requestHeaders: object, responseHeaders: object, requestBody: string, responseBody: string}'.
• Add dry-run parameter to burp_replay_flow and burp_send_raw_request. Example: 'dry_run: boolean (default: true), if true, simulate the request without sending it. Set to false only after confirming the mutation.'
• Replace burp_replay_flow 'request_mutations' object type with explicit schema: {type: 'object', properties: {headers: {type: 'object'}, body: {type: 'string'}, parameters: {type: 'object'}}, description: 'Mutations to apply: headers (key-value pairs), body (raw string), parameters (query/form params)'}.
• Add enum constraint to burp_rule_upsert 'action' in schema: {type: 'string', enum: ['modify', 'drop', 'spoof'], description: 'Action to perform...'}.
• Add error recovery guidance to tool descriptions. Example: 'If bridge connection fails, verify BURP_MCP_BRIDGE_URL is set and Burp extension is running. If rule installation fails, check rule_id is unique and match_pattern is valid regex.'