This server has critical definition quality issues. It registers only ONE tool ('vtex_*') with a generic, catch-all pattern rather than exposing 163+ individual tools with distinct names, schemas, and descriptions. The tool name 'vtex_*' is a wildcard that violates naming conventions, it does not start with a clear action verb, making it impossible for LLMs to infer intent from the name alone. The input schema is severely underspecified: path parameters, query parameters, and request bodies are all collapsed into three generic object properties without per-parameter type constraints, descriptions, or enums. The description mentions '163+ API endpoints' but provides no guidance on WHEN to use this tool, what specific endpoints it can call, or how to structure inputs correctly. Parameters lack individual descriptions, 'pathParams' and 'queryParams' are just generic objects with no indication of valid keys, types, or formats. The factory pattern in VtexToolFactory.ts generates schemas with only type:'string' for all parameters and minimal descriptions ('Path parameter: {param}', 'Query parameter: {param}'). There is no documented output schema, callers have no way to know what fields to expect from different endpoints. The tool requires users/LLMs to know VTEX API internals (endpoint paths, valid parameters) rather than exposing a clean, discoverable interface. Error handling in VtexToolHandler returns a generic {success, error} structure without recovery guidance. No idempotency hints, no rate limit warnings, no dependency documentation.

• CRITICAL: Refactor from single 'vtex_*' catch-all into 163+ distinct, named tools. Group endpoints by resource (e.g. vtex_products_*: get_product, list_products, create_product, update_product, delete_product). Each tool name must start with a clear action verb (get_, create_, update_, delete_, list_, search_).
• For each tool, define a complete input schema with per-parameter type constraints, enums where applicable, min/max for numerics, and descriptions. Example: {properties: {product_id: {type: 'string', description: 'Unique VTEX product identifier (10-50 chars, no spaces)'}, limit: {type: 'integer', minimum: 1, maximum: 100, description: 'Number of results to return (default: 20)'}}}
• Write tool descriptions as LLM prompts (50-200 chars): state WHAT (action), WHEN (use case), and WHAT IT RETURNS (key fields). Example: 'Fetch product details by ID. Returns name, price, inventory, categories. Use this before updating or displaying product info.'
• Document the output schema for each tool. Specify the response object structure, field types, and any IDs/references needed for downstream tool chaining. Example: {products: [{id: string, name: string, sku: string, price: number}], total_count: number}
• Add parameter descriptions that include constraints, valid ranges, and examples (conceptually, not literal example values). For enums, replace 'e.g. active, inactive' with a formal enum: {enum: ['active', 'inactive']}.
• Implement structured error responses that categorize errors and guide recovery. Pattern: {error: 'product_not_found', message: 'Product ID abc123 not found. Try search_products() with keyword or category.', retryable: false}