24 tools with consistent naming (verb_noun pattern) and basic schemas, but critical gaps in descriptions and parameter documentation. All tools have input schemas with types, but descriptions are generic (avg ~40 chars, well below 194-char baseline). Most parameters lack descriptions entirely. No output schemas documented. Error handling absent. Security concerns: no mention of credential injection or permission gates. Composition is reasonable (single responsibility per tool), but missing chaining IDs in responses and pagination guidance.

• Expand all tool descriptions to 50-200 characters. Example: 'razorpay_payments_get' → 'Retrieve full payment details including amount, status, method, and customer info. Use this to verify payment success or fetch transaction history. Returns payment_id, amount, status, created_at, customer_id.'
• Add descriptions to all parameters. For 'notes' fields, clarify: 'Custom key-value metadata (max 15 keys, 255 chars per value) for internal tracking. Not visible to customers.' For 'amount', specify: 'Amount in smallest currency unit (e.g., paise for INR). Must be >= 100.'
• Document output schemas for each tool. Create a schema map showing: razorpay_payments_get returns {payment_id, amount, status, method, customer_id, created_at, ...}. Include this in tool descriptions or a separate schema registry.
• Add error handling with actionable messages. Wrap razorpay_client calls in try-except. Return: 'Payment not found (ID: xyz). Check the ID or call razorpay_payments_list to find valid payments.' instead of raw exceptions.
• Enforce pagination limits. Cap 'count' at 50 for list tools. Update descriptions: 'razorpay_payments_list: List up to 50 payments. Use 'skip' to paginate. Returns total_count for iteration.' Add validation: if count > 50, clamp to 50 and log a warning.

Inferred effective spec: <=2025-11-25.

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