Critical failures across all dimensions. Tool definitions are inferred from the Stripe Agent Toolkit (external dependency), not directly visible in source code. No input schemas, parameter descriptions, or output schemas are defined in the MCP server code itself. Descriptions are generic one-liners (10-30 chars) that fail to explain WHEN to use each tool or what it returns. No error handling guidance, no parameter validation, no security annotations. The server acts as a thin wrapper delegating to an external toolkit, tool quality is opaque and unverifiable from this codebase.

• Audit @stripe/agent-toolkit and document all 20 tool schemas (input parameters, types, constraints, descriptions) in this MCP server's source or README. Make schemas verifiable without inspecting external dependencies.
• Expand tool descriptions to 100-200 chars. Include: what the tool does, when to use it vs similar tools, required prerequisites, and what it returns. E.g., 'Create a new coupon in Stripe with discount rules. Use this to generate promotional codes for campaigns. Returns coupon_id and discount details. Requires valid Stripe account.'
• Add parameter descriptions for all inputs. For each parameter, state its type, valid values/ranges, and format. E.g., 'coupon_id (string, required): Unique coupon identifier (alphanumeric, max 50 chars). Used to reference the coupon in future calls.'
• Implement error handling guidance. Catch Stripe API errors and return actionable messages: 'Invalid coupon_id: must be alphanumeric. Try search_coupons() to find valid IDs.' Classify errors as retryable (rate limit) vs user-fixable (invalid input) vs fatal (auth failure).
• Add tool annotations via MCP SDK. Mark read-only tools with readOnlyHint=true. Mark destructive tools (refunds.create, invoices.update) with destructiveHint=true and idempotentHint=false. This enables LLM safety guardrails.