Bazos MCP server has explicit tool registration with schemas and descriptions, but significant gaps limit production readiness. All 8 tools have descriptions (10-200 chars, mostly adequate) and input schemas with typed properties. However, output schemas are completely undocumented, LLMs cannot predict response structure for chaining. Parameter descriptions are present but often lack constraints (ranges, formats, dependencies). Error handling is minimal: generic catch-all exceptions with no recovery guidance. Security concerns: phone numbers and emails exposed as parameters; no mention of rate limiting despite explicit warnings about ban risk. Tool composition is reasonable (search, get, create, delete, verify) but lacks idempotency guarantees and confirmation patterns for destructive ops.

• Document output schemas for all tools. Example for search_ads: {type: object, properties: {ads: {type: array, items: {type: object, properties: {id: number, title: string, price: number, ...}}}, total_count: number, next_offset: number}}
• Remove phone/email from tool parameters. Instead: (1) store user credentials server-side after SMS verification, (2) use MRTR (result: {type: 'input_required', description: 'Enter SMS code'}) to request sensitive input without logging it.
• Add confirmation pattern to delete_ad: return {type: 'input_required', description: 'Confirm deletion of ad ID 12345 (title: "..."). Type DELETE to confirm.'} before executing.
• Replace generic error messages with actionable guidance. Example: 'Invalid offset: 250. Must be 0 - 200 in increments of 20 to avoid ban. Retry with offset=200.' Include error classification (retryable, user-fixable, fatal).
• Add parameter constraints: offset/limit as integers with minimum/maximum; phone as string matching regex ^\+420\d{9}$; price_type as enum in search_ads if applicable; required fields marked in schema.