This server exposes a single tool 'search_body' with adequate basic structure but significant gaps in pattern adherence. The tool has a reasonable name (verb-noun format: search_*) and a generic description, but lacks critical pattern implementations: no pagination support despite potentially returning large result sets, no error handling guidance, no structured output documentation, and no output schema visible in the code. The parameter schema is visible and typed, but several parameters lack depth in their descriptions. Overall, this is a fair-to-poor implementation that would benefit from pagination, explicit output schema documentation, and richer error guidance. Tool definitions are directly visible (not inferred), so they score at full weight rather than capped at 50.

• Add explicit output schema documentation. Example: 'Returns an object with {total_count: int, matches: [{location: string, context: string, score: float}], has_more: bool, next_cursor: string}'. This lets LLMs understand the response structure before calling the tool.
• Implement cursor-based pagination. Change tool signature to accept 'cursor' parameter (optional, default null) and return 'next_cursor' in response. This prevents context window exhaustion on large result sets.
• Expand tool description to 150 - 250 characters. Include: what the tool does, when to use it, what it returns, and any side effects. Example: 'Search for text across captured HTTP request and response bodies. Use this to find data patterns, errors, or headers in previous requests. Returns up to 10 matches with context snippets. If no results found, try broadening the query or checking the host filter.'
• Add constraints to parameter descriptions: (1) 'query': max 500 characters, case-insensitive by default; (2) 'host': domain name or IP address; (3) 'limit': integer 1 - 100 (not default 10 in description, put it in schema as minimum/default); (4) 'in_body': must be one of 'request', 'response', or 'both' (express as enum in schema, not free-form string).
• Document error scenarios. Add to tool description or create a separate errors section: 'If query is empty, returns 400 with message: Invalid query, must be 1 - 500 characters. If no matches found, returns 200 with empty matches array and total_count=0. If host filter does not match any captured requests, returns 200 with total_count=0.'

Inferred effective spec: 2025-06-18+.

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