gori MCP Server provides 29 tools with basic parameter schemas and descriptions, but exhibits significant quality gaps typical of community servers. While tool names follow verb_noun conventions (decode, create_repeater, list_issues), descriptions are inconsistent in depth and clarity. Most tools have JSON Schema input definitions with type annotations, but several lack critical parameter documentation, constraint specifications, and error guidance. Output schemas are not documented in source code. The server operates as a web security testing proxy integration (Burp-suite-like) with both read-only discovery tools and destructive write operations, but lacks proper permission gating and confirmation patterns for irreversible actions. Parameter validation rules are sparse, and recovery guidance in errors is absent.

• Document output schema for every tool in source code or specification file. Include field names, types, and descriptions. Example for get_repeater_context: returns {id: int, target: string, name: string, request: string, response: string, created_at: ISO8601, ...}
• Add error classification and recovery guidance to all tool descriptions. Format: 'On error: [retryable|user-fixable|fatal]. If not found, try search_* tools. If rate-limited, wait 60s and retry.'
• Implement multi-step confirmation for destructive tools. Pattern: intercept_drop could return {action: 'confirm_delete', flow_id: 123, preview: '...'} and require a confirm_intercept_drop(flow_id, confirmation_token) second call.
• Specify mutual exclusivity and constraints in parameter descriptions. Example for create_repeater: 'Either provide request (raw payload) OR flow_id OR issue_id; passing multiple is an error. flow_id must be a positive integer.'
• Add pagination to list tools: list_history(limit=20, offset=0) → {flows: [...], total: 1500, next_offset: 20}. Document reasonable defaults (limit=20, max=100).
• Declare permission requirements for each tool. Example: create_repeater requires 'write:repeater'; intercept_drop requires 'write:intercept'; send_request requires 'write:flows'. Document in descriptions.
• Clarify fuzz_start and mine_start parameter expectations. Either require explicit session config parameters or document that they use project-level defaults. Provide an example invocation.
• Ensure response types include IDs/references needed by downstream tools. If get_repeater_context returns a repeater ID, include flow_id as well so compare_flows can be called immediately without extra lookup.